Özel yazılım projelerinde en zor sorulardan biri “Bu özellik ne zaman tamamlanmış sayılacak?” sorusudur. “Kullanıcı siparişleri yönetebilmeli” veya “rapor hızlı açılmalı” gibi cümleler ihtiyacı kabaca anlatır; fakat test edilebilir bir sonuç tarif etmez. Geliştirme sonunda müşteri farklı, yazılım ekibi farklı bir tamamlanma ölçüsü kullanırsa çalışan bir ürün ortaya çıksa bile teslim tartışmalı hale gelir.
Kabul kriterleri, bir özelliğin iş ihtiyacını karşıladığını göstermek için doğrulanması gereken açık koşullardır. Gereksinimin yerine geçmez; onu gözlemlenebilir hale getirir. Kim, hangi başlangıç koşulunda, hangi işlemi yaptığında sistemin ne sonuç üretmesi gerektiğini belirtir. Bu sayede kapsam, geliştirme, test ve iş birimi onayı aynı referans üzerinden ilerler.
1. Kabul kriterini ekran listesinden ayırın
“Müşteri ekranı yapılacak, filtre eklenecek, Excel butonu olacak” şeklindeki liste neyin geliştirileceğini söyler; fakat iş sonucunu açıklamaz. Filtrenin hangi alanlarda çalışacağı, hangi kullanıcının hangi müşterileri görebileceği, dışa aktarılan dosyada hangi sütunların bulunacağı ve veri yoksa sistemin nasıl davranacağı belirsiz kalır.
Önce iş hedefini ve kullanıcı akışını yazın. Örneğin satış sorumlusu yalnızca kendisine atanmış açık talepleri tarih aralığına göre filtreleyip raporlayabilsin. Ardından bu akışı kanıtlayan koşulları belirleyin. Kabul kriteri çözümün her teknik ayrıntısını dayatmamalı; ancak yanlış veya eksik bir uygulamanın onaylanmasını engelleyecek kadar kesin olmalıdır.
İyi kabul kriteri, geliştiriciye neyi kanıtlaması gerektiğini; iş birimine de neyi onayladığını gösterir.
2. Kriterleri kullanıcı, koşul, işlem ve sonuçla yazın
Her kriter dört soruya cevap verebilir: İşlemi hangi rol yapıyor, başlangıçta hangi veri veya durum var, kullanıcı ne yapıyor ve sistem hangi gözlemlenebilir sonucu üretiyor? Bu yapı teknik olmayan ekiplerin de senaryoyu okuyup doğrulamasını kolaylaştırır. Bir kriter içinde çok fazla davranış varsa onu daha küçük maddelere bölün.
Örneğin “Onay sistemi çalışmalı” yerine şu koşullar ayrı ayrı yazılabilir: Satış sorumlusu taslak teklifi onaya gönderdiğinde durum “Onay Bekliyor” olur; onay yetkisi olmayan kullanıcı kabul veya ret işlemi yapamaz; yönetici reddettiğinde gerekçe zorunludur; karar sonrasında teklif sahibi bildirim alır ve işlem geçmişinde kullanıcı ile zaman kaydedilir. Böylece mutlu akışın yanında yetki ve kayıt beklentileri de sınanır.
- Kriter tek ve gözlemlenebilir bir davranışı tarif ediyor mu?
- Beklenen sonuç “doğru”, “hızlı” veya “uygun” gibi yoruma açık kelimelerden arındırıldı mı?
- Gerekli kullanıcı rolü ve başlangıç verisi belli mi?
- Başarılı işlemin yanında hata ve yetkisiz erişim durumu yazıldı mı?
- Kriter, iş birimi tarafından test ortamında tekrar uygulanabilir mi?
3. Sadece başarılı akışı değil istisnaları da tanımlayın
Gerçek operasyon her zaman eksiksiz veriyle ve doğru sırayla ilerlemez. Aynı kayıt iki kez gönderilebilir, zorunlu alan boş kalabilir, entegrasyon yanıt vermeyebilir veya kullanıcı yetkisi dışında bir işlemi deneyebilir. Kabul kriterleri yalnızca sorunsuz senaryoyu kapsarsa sistem demo sırasında çalışır, günlük kullanımda ise ekibin elle müdahalesine ihtiyaç duyar.
Her önemli akış için sınırları sorun: Minimum ve maksimum değer nedir, tarih aralığı ters girilirse ne olur, mükerrer kayıt nasıl tanınır, bağlantı kesilirse işlem tekrar edilebilir mi, kısmen tamamlanan işlem geri alınır mı? Kullanıcıya gösterilecek hata mesajı anlaşılır olmalı; teknik ayrıntıyı ifşa etmeden sorunun nasıl düzeltileceğini anlatmalıdır. Kritik hatalar ayrıca izleme kaydına düşmeli ve sorumlu ekibe bildirilebilmelidir.
4. Veri, rol, entegrasyon ve performansı ayrı başlıklarda ele alın
Fonksiyonun doğru düğmeye basınca çalışması tek başına kabul için yeterli değildir. Oluşan verinin biçimi, zorunlu alanları, ilişkileri ve değişiklik geçmişi kontrol edilmelidir. Veri taşıması yapılıyorsa kaynak ve hedef kayıt sayıları, dönüştürme kuralları, reddedilen kayıtların raporu ve örneklem doğrulaması baştan tanımlanmalıdır. Aksi halde ekran doğru görünürken arka planda eksik veya tekrarlı kayıtlar kalabilir.
Rol ve yetki kriterlerini “yönetici her şeyi görür” düzeyinde bırakmayın. Kullanıcının hangi kayıtları görebildiği, oluşturabildiği, değiştirebildiği, silebildiği ve dışarı aktarabildiği rol bazında yazılmalıdır. Özellikle fiyat, kişisel veri, finansal alan veya toplu indirme gibi hassas işlemler için erişim ve işlem geçmişi ayrı doğrulanmalıdır.
Entegrasyonlarda yalnızca başarılı yanıt değil; zaman aşımı, geçersiz veri, oran sınırı, tekrar deneme ve aynı işlemin iki kez oluşmasını engelleme davranışı tanımlanmalıdır. Hangi sistemin ana veri kaynağı olduğu ve uyuşmazlıkta hangi kaydın geçerli sayılacağı belirlenmelidir. Test ortamı ile canlı ortam anahtarları, adresleri ve örnek verileri birbirinden ayrılmalıdır.
“Ekran hızlı açılmalı” ölçülemez. İş açısından kritik işlemler için veri hacmi, eş zamanlı kullanıcı sayısı, cihaz veya bağlantı koşulu ve kabul edilen yanıt süresi birlikte yazılabilir. Her ekrana rastgele bir saniye hedefi koymak yerine satış, sipariş, rapor veya üretim akışını gerçekten etkileyen noktaları ölçün. Güvenlik, yedekleme, tarayıcı desteği ve erişilebilirlik gibi fonksiyon dışı gereksinimleri de proje sonuna bırakmayın.
5. Kullanıcı kabul testini gerçekçi veriyle planlayın
Kullanıcı kabul testi, geliştirme ekibinin yaptığı teknik testlerin tekrarı değildir. Sistemi günlük işinde kullanacak temsilciler, belirlenen kabul kriterlerini gerçek operasyona benzeyen senaryolarla doğrular. Her rol için süreci iyi bilen ve karar verebilen bir sorumlu seçin. Test tarihini teslim haftasında boşluk bulunursa yapılacak bir etkinlik olarak değil, proje planının ayrı bir aşaması olarak belirleyin.
Test ortamında kişisel veya ticari açıdan hassas canlı veriyi gelişigüzel kopyalamayın. Kimliksizleştirilmiş fakat çeşitliliği ve sınır durumlarını temsil eden veri setleri hazırlayın. Test adımını, beklenen sonucu, gerçekleşen sonucu, ekran görüntüsü veya kaydı, önem derecesini ve sorumluyu aynı yerde tutun. “Bende çalışmadı” gibi tekrar üretilemeyen bildirimlerin yerine hangi kullanıcı, veri ve adımda hata oluştuğu görünür olur.
- Kritik iş akışlarının tamamı için test senaryosu hazırlayın.
- Her senaryoyu sorumlu kullanıcı rolüyle çalıştırın.
- Normal veriyle birlikte boş, hatalı, mükerrer ve sınır değerleri deneyin.
- Entegrasyon kesintisi veya gecikmesini güvenli biçimde simüle edin.
- Bulunan hatayı önem, iş etkisi, sorumlu ve yeniden test tarihiyle kaydedin.
- Düzeltmeden sonra ilgili akışın tamamını yeniden doğrulayın.
6. Onay, hata sınıfları ve kapsam değişikliğini yönetin
Her hata teslimi durdurmak zorunda değildir; fakat sınıflandırma baştan bilinmelidir. Veri kaybı, güvenlik ihlali, temel iş akışının çalışmaması veya geri dönüşü olmayan yanlış işlem kritik kabul edilebilir. Küçük bir hizalama sorunu ise yayın sonrası plana alınabilir. Önem derecesinin yalnızca teknik ekibin tahminiyle değil, iş etkisiyle belirlenmesi gerekir.
Test sırasında yeni bir ihtiyaç bulunması her zaman hata anlamına gelmez. Sistem yazılı kritere uygun çalışıyor fakat kullanıcı farklı davranış istiyorsa bu bir kapsam değişikliğidir. Değişikliğin etkisi, önceliği, süre ve maliyet karşılığı değerlendirilerek mevcut teslimden ayrılmalıdır. Aksi halde kabul testi bitmeyen bir özellik toplama oturumuna dönüşür.
Son onayda geçen kriterler, açık hatalar, geçici çözümler, kapsam dışı maddeler, canlıya geçiş koşulları ve yayın sonrası destek sorumlulukları kayda alınmalıdır. Eğitim, yönetici erişimleri, dokümantasyon, yedekten dönüş ve izleme gibi operasyonel teslimler de ürünün parçasıdır. İmzalı bir kabul kaydı kusursuzluk iddiası değil, hangi sürümün hangi koşullarla devralındığını gösteren ortak hafızadır.
Ölçülebilir kabul kriterleri özel yazılım projesini katılaştırmaz; belirsizliği azaltır. İş hedefi kullanıcı senaryolarına, senaryolar gözlemlenebilir sonuçlara ve sonuçlar tekrarlanabilir testlere dönüştüğünde ekipler sorunları daha erken konuşur. Teslim günü ilk kez “çalışıyor” kelimesinin anlamını tartışmak yerine, proje boyunca aynı tamamlanma tanımını kullanır.