Yazılım tesliminde belirsiz onay yerine kullanıcı görevi, başlangıç verisi, beklenen sonuç ve hata durumlarıyla uygulanabilir kabul testi hazırlama yöntemi.
“Ekran çalışıyor” teslim ölçütü değildir. Kabul kriteri, belirli bir kullanıcının belirli veride yaptığı işlemin hangi sonucu üretmesi gerektiğini açıklar.
Kullanıcı kabul testi, yazılım ekibinin hata aramasından farklıdır. Amaç, sistemin işletmenin gerçek görevini baştan sona tamamlayabildiğini iş sahibiyle doğrulamaktır. Senaryo yalnızca mutlu yolu içerirse yetki, eksik veri, iptal ve tekrar deneme sorunları canlıda ortaya çıkabilir.
Kabul kriterleri proje sonunda yazılmamalıdır. İhtiyaç görüşmesinde oluşturulursa ekran ve veri kararlarını yönlendirir; teslimde “beklediğimiz bu değildi” tartışmasını azaltır.
İyi bir kabul kriterinin dört parçası
- Rol: İşlemi yapan kullanıcı veya sistem.
- Başlangıç koşulu: Testten önce var olması gereken veri ve durum.
- Eylem: Kullanıcının tamamladığı adımlar.
- Beklenen sonuç: Ekran, veri, bildirim ve işlem kaydında oluşması gereken çıktı.
Örneğin “Şube yöneticisi, bekleyen siparişi onayladığında sipariş hazırlanıyor durumuna geçmeli; stok rezervasyonu oluşmalı ve işlemi yapan kullanıcı kaydedilmelidir.” Bu cümle hem arayüzü hem arka plandaki iş sonucunu sınar.
Senaryo seti yalnızca başarılı akıştan oluşmaz
- Eksik veri: Zorunlu alan boş veya biçimi geçersiz olduğunda açıklayıcı hata.
- Yetkisiz işlem: Rolü olmayan kullanıcı doğrudan adresi çağırdığında erişimin engellenmesi.
- Tekrar deneme: Kullanıcı butona iki kez bastığında çift kayıt oluşmaması.
- İptal ve geri alma: İş kuralına uygun durumlarda kaydın iz bırakacak biçimde geri çevrilmesi.
- Entegrasyon hatası: Uzak servis yanıt vermediğinde verinin kaybolmaması ve yeniden denemenin görünmesi.
- Sınır değer: Uzun metin, yüksek miktar, tarih sınırı veya boş liste durumunun doğru işlenmesi.
Test verisi gerçeğe benzemeli, gerçek kişi verisi olmamalı
UAT ortamında üretim verisini kontrolsüz kopyalamak yerine gerçek iş çeşitliliğini temsil eden sentetik kayıtlar hazırlanmalıdır. Farklı şube, rol, ürün türü, vergi durumu veya sipariş aşaması gibi senaryoyu etkileyen ayrımlar bulunmalıdır.
Test verisi çok düzenli olursa günlük kullanımda görülen eksik kod, eski kayıt veya tekrar müşteri gibi durumlar sınanmaz. Bununla birlikte kişisel ve hassas veri gereksiz yere test ortamına taşınmamalıdır.
Hata kaydı geliştiriciye yeniden üretilebilir bilgi vermeli
| Alan | Örnek içerik türü |
|---|---|
| Senaryo kodu | UAT-SIPARIS-07 gibi benzersiz kimlik |
| Ortam ve sürüm | Test adresi ile dağıtım/sürüm bilgisi |
| Başlangıç verisi | Kullanılan rol, kayıt ve mevcut durum |
| Uygulanan adımlar | Hatayı oluşturan sıralı eylemler |
| Beklenen/gerçek sonuç | İki sonucun açık farkı |
| Kanıt | Kişisel veri içermeyen ekran veya hata kimliği |
Kabul toplantısı nasıl tamamlanır?
Senaryoları gerçek işi yapan kullanıcılar uygular; proje sahibi kritik sonuçları onaylar. Başarısız senaryolar önem ve iş etkisine göre sınıflandırılır. Kritik iş akışı geçmeden canlıya çıkılmaz; düşük etkili düzeltmeler için açık tarih ve sorumlu yazılır.
İmzalanan kabul yalnızca “uygundur” cümlesi değil, çalıştırılan senaryo listesi ve sonuçlarıdır. İhtiyaç dokümanı hazırlama aşamasındaysanız kabul ölçütlerini proje kapsamına nasıl ekleyeceğinizi inceleyebilirsiniz. Özel bir iş akışını değerlendirmek için proje görüşmesi talebi oluşturabilirsiniz.
Bu rehberden ne öğreneceksiniz?
- Dijital yatırım kararını somut ölçütlerle vermek isteyen işletme sahipleri
- Teknik kapsamı sade bir dille anlamak isteyen proje yöneticileri
- Teklifleri ve çözüm seçeneklerini karşılaştıran ekipler
Karar verirken kontrol edin
- İş hedefi ve beklenen sonucun açık tanımı
- Kullanıcı, veri ve entegrasyon gereksinimleri
- Güvenlik, performans ve bakım sorumlulukları
- Başarıyı gösterecek ölçülebilir kriterler