Kavramın hikâyesi
Önce iş karşılığını gör, gerektiğinde bağlamı aç.
İlk taramaİşte karşılaşacağın sinyaller
Gerilim ve çözüm · Bölüm 01
Hangi problemi çözer?
Beklenen sonucu gözlenebilir hâle getirir, kapsam anlaşmazlıklarını daha erken ortaya çıkarır ve kabul testleri için dayanak sağlar. “Buton çalışsın” yerine hangi kullanıcıda, hangi koşulda ve hangi sonucun beklendiğini görünür kılar.
Gerçek hayat · Bölüm 02
Gerçek iş senaryosu
SCN-001'de “Kullanıcı profilini güncelleyebilmeli” kriteriyle karşılaştığını düşün. Hangi alanların düzenlenebildiğini, geçersiz veride ne olacağını, başarılı kaydın nasıl gözleneceğini ve yetkisiz kullanıcının hangi davranışla karşılaşacağını sorarsın.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Uygulama teknolojisini kriter diye yazmak yerine kullanıcı açısından gözlenebilir sonuçları netleştirirsin.
Duyacağın bağlam · Bölüm 03
Ekipte bunu nasıl duyabilirsin?
Temsili ekip konuşması: “Bu kriter başarılı akışı söylüyor; geçersiz veri ve yetki sınırı için beklenen davranışı da netleştirebilir miyiz?”
Beklenti seviyesi · Bölüm 04
Junior hangi seviyede bilmeli?
- Tanı: Bir ticket içindeki Acceptance Criteria bölümünü iş açıklaması ve teknik görevlerden ayırabilmelisin.
- Açıkla: Kriterlerin ortak anlayış ve doğrulama için neden kullanıldığını anlatabilmelisin.
- Uygula: Belirsiz bir ifadeyi gözlenebilir sonuca dönüştürmek için örnek, sınır ve başarısızlık davranışı sorabilmelisin.
- Şimdilik bilmesi gerekmeyen: BDD araçları, Gherkin söz dizimi, kapsamlı test otomasyon mimarisi ve kurumsal gereksinim yönetimini şimdilik öğrenmen gerekmez.
İhtiyacın kökeni · Bölüm 05
Neden ortaya çıktı?
Kısa bir iş açıklamasındaki “tamamlandı” ifadesini ürün, geliştirme ve test rolleri farklı yorumlayabilir. Acceptance Criteria, beklenen davranışları iş başlamadan veya iş sürerken konuşup görünür kılmaya yardım eder.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Kriterler bu konuşmanın çıktısıdır; paydaş konuşmasının yerine geçen değişmez bir sözleşme değildir.
Ekip etkisi · Bölüm 06
Şirketler neden kullanır?
Ekipler, aynı iş öğesinin beklenen sonucunu ürün, geliştirme ve test açısından karşılaştırabilmek için Acceptance Criteria kullanabilir.
Tam bağlamı açGerekçe, sınırlar ve kalan ayrıntı
Azure Boards dokümantasyonunda kriterler bir bug veya user story'nin kapanış koşulları ve acceptance testlerinin dayanağı olarak ele alınır. Bu, belirli bir araç ve süreç örneğidir; bütün şirketler için zorunlu bir yöntem değildir.
Karar alanı · Bölüm 07
Trade-off ve bağlam
Çok belirsiz kriterler farklı yorumları engellemez. Aşırı ayrıntılı veya teknik çözümü kilitleyen kriterler ise keşfi ve uygulama seçeneklerini gereksiz yere daraltabilir. Kriterler yeni bilgi geldikçe paydaşlarla konuşularak netleştirilebilir; sessizce değiştirilmemelidir.
Yanılgı radarı · Bölüm 08
Yaygın yanlış anlamalar
- “Acceptance Criteria, Scrum'ın zorunlu artefact'ıdır.” Yanlış; Scrum Guide bu kavramı kanonik bir Scrum artefact'ı veya commitment'ı olarak tanımlamaz.
- “Acceptance Criteria ile Definition of Done aynıdır.” Yanlış; kapsamları farklıdır.
- “Her kriter otomatik test olmalıdır.” Kaynakların desteklemediği genelleme; doğrulanabilirlik otomasyon zorunluluğu değildir.
- “Kriterler çözümün nasıl kodlanacağını söylemelidir.” Genellikle beklenen sonucu tarif etmek daha uygundur; teknik kısıt gerçekten varsa ayrıca görünür kılınmalıdır.
- “Acceptance Criteria varsa konuşmaya gerek kalmaz.” Yanlış; kaynaklar kriterlerin konuşmayla netleştirilmesinin ortak anlayışa yardım ettiğini gösterir.
Gerilim ve çözüm1. bölüm