Cevap.

Tarihsel olarak, kabul kriterlerinin formülasyonu test uzmanları veya geliştirme ekibinin sorumluluğundaydı. Ancak, esnek ölçekteki süreçlere (SAFe, LeSS, Scrum-of-Scrums) geçişle birlikte, formalize edilmemiş test senaryoları, büyük projelerde farklı katılımcılar arasında beklenti uyumsuzluğu risklerini artırıyor: iş, test, geliştiriciler ve destek, görevin tamamlandığını farklı şekilde yorumlayabilir.

Çoklu ekipler veya dağıtılmış projelerdeki sorun: farklı sorumluluk alanları, farklı süreçler ve araçlar, ekipler arasında dil veya kültürel farklılıklar. Detaylı bir şekilde hazırlanmış talepler bile, çatışmalı veya eksik kabul kriterlerine dönüşebilir, bu da hatalara ve işin memnuniyetsizliğine yol açar.

Çözüm, sistem analistini kabul kriterlerinin oluşturulmasının erken aşamalarında dahil etmek, ekipler arasında talepleri koordine etmek, katı bir formizasyon ve ortak bir demo veya grup çalıştayında senaryolar ve kenar durumları (edge-cases) üzerinde ortak tartışma yapmaktır.

Anahtar noktalar:

Kabul kriterleri açık, ölçülebilir, tekrar edilebilir ve doğrulanabilir olmalıdır.
Önceden onaylama kriterleri (manuel kontrol listesi + beklenen verilerin/davranışların örnekleri).
Karşılıklı izleme: kriterler her zaman taleplere, durumlara ve kullanıcı hikayelerine atıfta bulunmalıdır, böylece her hedef izlenebilir.

Kandırmaca Sorular.

Kabul kriterlerinin formülasyonunu tamamen test uzmanlarına bırakmak mümkün mü?

Hayır, analistin katılması zorunludur. Sadece o, iş bağlamının tamamına sahiptir ve taleplerin tüm inceliklerini bilir.

Kabul kriterlerinin sadece olumlu senaryoları kapsaması mı gerekir?

Hayır, kesinlikle olumsuz ve kenar durumlarını (edge cases) da eklemek gerekir, aksi halde uygulamada ve testte boşluklar oluşur.

Çoklu ekip projelerinde kabul kriterlerini sözlü olarak tanımlamak mümkün mü?

Hayır, sözlü anlaşmalar dağıtık etkileşim yüküne dayanamıyor ve çatışmalara yol açıyor. Kriterler yalnızca formalize edilmiş bir şekilde kabul edilir (örneğin Gherkin/BDD veya yapılandırılmış kontrol listeleri şeklinde).

Tipik Hatalar ve Anti-Desenler

Kabul kriterlerinin "varsayılan" olarak formüle edilmesi, taleplere ve spesifikasyonlara atıfta bulunmadan.
Son ekiplerden geri bildirim alınmaması.
Farklı ekipler arasındaki bileşen etkileşim senaryolarının göz ardı edilmesi, özellikle entegrasyonlarda.

Hayatından bir Örnek

Olumsuz durum: Bankacılık uygulamasında kabul kriterleri yalnızca bir ekip ile mutabık kalınarak belirlenmiştir. İkinci ekip, ilk kriter bloğunu dikkate almadan kendi iç arayüzlerini geliştirmiştir, bu da işlem kimliklerinin formatında uyuşmazlıklara yol açmıştır.

Artıları:

Hızlı bir uygulama başlangıcı.

Eksileri:

API’yi yeniden düzenleme ihtiyacı.
Çatışmaları çözmek için zaman kaybı.

Olumlu durum: Analist, tüm katılan ekipler için görsel senaryolar ve detaylarla bir dizi çalıştay düzenlemiş ve kabul kriterlerini Confluence/JIRA’da iki yönlü izleme ile yazılı olarak kaydetmiştir.