Verilen-Ne Zaman-O Zaman Kabul Kriterleri Açıklaması
Biçim: Verilen-ne zaman-o zaman kriterleri, ekip üyeleri arasında ortak anlayış sağlamak için açık ve test edilebilir yazılım davranışını tanımlar.
Yapı: Biçimdeki her senaryo; bağlamı, kullanıcı eylemini ve beklenen sonucu yalın bir dille içerir.
En İyi Uygulamalar: Kabul kriterlerinin açıklığını artırmak için sadeliğe, iş birliğine ve ayrıntıya odaklanın.
Yaygın Hatalar: Senaryoları bir araya sıkıştırmaktan, teknik ayrıntılar yazmaktan ve uç durumları göz ardı etmekten kaçının.
GWT (Ön Koşul-Eylem-Sonuç) kabul kriterleri, geliştiricilerin, test uzmanlarının ve paydaşların ortak bir anlayışa sahip olması için yazılımın nasıl davranması gerektiğini açıklamanın basit ve test edilebilir bir yolunu sunar. Kabul kriterleri belirsiz olduğunda ekipler gereksinimleri tartışarak, yanlış çözümü oluşturarak ve geliştirmenin ilerleyen aşamalarında eksikleri bularak zaman kaybeder.
Bu kılavuzda Ön Koşul-Eylem-Sonuç biçimini açıklayacak, yaygın senaryolardaki gerçek örnekleri gösterecek, bu biçimi diğer kabul kriteri yaklaşımlarıyla karşılaştıracak ve çevik ekiplerin daha açık ve etkili kullanıcı hikâyeleri yazmasına yardımcı olan uygulamaları paylaşacağım.
Ön Koşul-Eylem-Sonuç Kabul Kriterleri Nedir?
Ön Koşul-Eylem-Sonuç, bir kullanıcı hikâyesi için kabul kriterleri yazmaya yönelik üç parçalı bir şablondur. Her senaryo, geliştiricilerin, test uzmanlarının ve paydaşların okuyabileceği sade bir dille beklenen davranışın bir bölümünü açıklar.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Yapının işleyişi şöyledir:
- Ön Koşul son kullanıcının herhangi bir işlem yapmasından önce zaten doğru olması gereken durumu belirtir.
- Eylem eylemi tanımlar. Kullanıcının yaptığı işlem veya sistemin tetiklediği olaydır.
- Sonuç sonucu ortaya koyar. Sistemin doğru yanıt verdiğini kanıtlayan sonuçtur.
Ön Koşul-Eylem-Sonuç Kabul Kriterleri Nasıl Yazılır?
Her bir ifadeyi geliştirme ve yazılım testi sırasında geçerliliğini koruyacak şekilde nasıl yazacağınızı öğrenin.
Ön Koşul: Bağlamı ve Ön Koşulları Belirleme
Ön koşul ifadesi, zaten doğru olması gereken durumu açıklar. Buna sistem durumu, kullanıcı rolü, veri koşulları ve ortam kurulumu dahildir. Güçlü ön koşul ifadeleri özeldir. Senaryo role bağlı olduğunda “Ön Koşul kullanıcı oturum açmış durumda” yazmaktan kaçının. Bunun yerine “Ön Koşul geçerli bir aboneliğe sahip kayıtlı bir müşteri hesap ayarları sayfasında” yazın.
Ön koşul ifadesini yazmaya yönelik birkaç kılavuz:
- Önemli olduğunda kullanıcı rolünü veya kişiliğini belirtin.
- Özellik bayrakları, veri durumları veya bağlantı gibi sistem koşullarını belirtin.
- Birden fazla ön koşulu tek bir ifadeye sıkıştırmak yerine “Ve” ile birleştirin.
Eylem: Eylemi veya Tetikleyiciyi Tanımlama
Eylem ifadesi, test ettiğiniz davranışı tetikleyen eylemi veya olayı yakalar. Bir dizi değil, tek bir kullanıcı etkileşimini veya sistem olayını açıklamalıdır. Etken çatı kullanın. “Kupon düğmesine tıklanır” yerine “Eylem müşteri ‘Kupon Uygula’ düğmesine tıklar” yazın. Bu, eylemi kimin gerçekleştirdiğine dair belirsizliği ortadan kaldırır.
Bu ifadeyi kısa tutun. Birden fazla eylem ifadesine ihtiyacınız varsa muhtemelen iki ayrı senaryoyu açıklıyorsunuzdur. Bunları ayırın.
Sonuç: Beklenen Sonucu Belirtme
Sonuç ifadesi, eylemden sonra kullanıcının ne görmesi veya sistemin ne yapması gerektiğini belirtir. Gözlemlenebilir sonuçları açıklayın. “Sonuç gösterge tablosu yüklenir” zayıf bir ifadedir. “Sonuç sistem müşterinin gösterge tablosunu iki saniye içinde görüntüler” test edilebilir bir ifadedir. Hata mesajları, yönlendirme hedefleri, veri değişiklikleri, e-posta tetikleyicileri veya kullanıcı arayüzü durumu değişiklikleri gibi ayrıntılara yer verin.
Tek bir eylem birden fazla gözlemlenebilir sonuç ürettiğinde, birden fazla sonucu birbirine bağlamak için Ve kullanın. Örneğin, “Sonuç sipariş onay sayfası görüntülenir” Ve “müşteri 60 saniye içinde bir onay e-postası alır.”
Ön Koşul-Eylem-Sonuç Örnekleri
Aşağıda farklı alanlardaki Ön Koşul-Eylem-Sonuç kabul kriterlerine ilişkin bazı örnekler yer almaktadır.
Kullanıcı Oturumu Açma
Senaryo 1: Geçerli kimlik bilgileriyle başarılı oturum açma
Ön Koşul kayıtlı bir kullanıcı oturum açma sayfasındadır Eylem kullanıcı geçerli bir e-posta ve doğru parolayı girip “Oturum Aç” düğmesine tıklar Sonuç sistem kullanıcıyı hesap gösterge tablosuna yönlendirir
Buradaki ön koşul ifadesi kasıtlı olarak kısa tutulmuştur; çünkü senaryo abonelik düzeyine veya hesap durumuna bağlı değildir. Birleşik eylem ifadesine dikkat edin: kimlik bilgilerini girmek ve bir düğmeye tıklamak tek bir mantıksal eylemdir (oturum açma formunu göndermek); bu nedenle her tuş vuruşu için ayrı bir senaryoya bölmek yerine bunları birlikte tutuyorum.
Senaryo 2: Geçersiz kimlik bilgileriyle başarısız oturum açma
Verilen kayıtlı bir kullanıcı giriş sayfasındadır Ne zaman kullanıcı geçerli bir e-posta ve yanlış bir parola girip "Giriş Yap" seçeneğine tıklarsa Sonra sistem "Geçersiz e-posta veya parola" mesajını görüntüler Ve kullanıcı giriş sayfasında kalır
Sonra cümlesi, tam hata mesajı metnini belirtir. İkinci Ve cümlesi önemlidir; çünkü kullanıcının yanlışlıkla başka bir yere yönlendirilmediğini doğrular.
Alışveriş Sepeti ve Ödeme
Senaryo 1: Sepete ürün ekleme
Verilen müşteri stokta bulunan bir ürünün ayrıntı sayfasını görüntülüyor Ne zaman müşteri "Sepete Ekle" seçeneğine tıklarsa Sonra sepet simgesi bir ürünü gösterecek şekilde güncellenir Ve bir onay mesajında "Ürün sepete eklendi" yazısı görüntülenir
Verilen cümlesinde "stokta bulunan" ifadesi yer alır; çünkü stokta olmayan ürünlerde davranış farklıdır ve bu ayrı bir senaryodur.
Senaryo 2: Geçerli bir indirim kodu uygulama
Verilen müşterinin sepette toplamı $80.00 olan iki ürünü var Ne zaman müşteri "SAVE20" indirim kodunu girip "Uygula" seçeneğine tıklarsa Sonra sistem %20 indirim uygular Ve sepet toplamı $64.00 olarak güncellenir
Belirli dolar tutarları yanlış yorumlamayı imkânsız hâle getirir. Bu tür bir indirim senaryosu, tek bir toplam üzerinden uygulanan yüzde indiriminin üç ondalık basamaklı bir fiyat oluşturduğu üretim ortamındaki yuvarlama hatasının yakalanmasına yardımcı olabilir. Verilen cümlesindeki ($80.00) ve Sonra cümlesindeki ($64.00) kesinlik, senaryoyu değerli kılan unsurdur.
Parola Kurtarma
Senaryo 1: Kayıtlı bir e-posta ile parola sıfırlama talebinde bulunma
Verilen kullanıcı giriş sayfasındadır Ne zaman kullanıcı "Parolamı Unuttum" seçeneğine tıklayıp kayıtlı bir e-posta adresi girdikten sonra "Gönder" seçeneğine tıklarsa Sonra sistem "E-postanıza bir sıfırlama bağlantısı gönderildi" mesajını görüntüler Ve sistem 60 saniye içinde parola sıfırlama e-postası gönderir
Buradaki birleşik Ne zaman cümlesi tek bir mantıksal akışı, yani sıfırlama talebinde bulunmayı temsil eder. Sonra cümlesindeki 60 saniyelik süre kısıtlaması kritik öneme sahiptir. Bu kısıtlama olmadan 20 dakika sonra ulaşan bir sıfırlama e-postası teknik olarak "başarılı" sayılır. Zamana bağlı sonuçlar, en sık atlanan ayrıntılardan biridir.
Senaryo 2: Süresi dolmuş bir sıfırlama bağlantısını kullanma
Verilen kullanıcı parola sıfırlama e-postasını 24 saatten daha uzun süre önce aldı Ne zaman kullanıcı e-postadaki sıfırlama bağlantısına tıklarsa Sonra sistem "Bu bağlantının süresi doldu. Lütfen yeni bir sıfırlama talebinde bulunun." mesajını görüntüler
Verilen cümlesi bir zaman koşulu içerir ve bu da sürenin ne kadar olması gerektiği konusunda bir görüşmeyi zorunlu kılar.
Form Doğrulama
Senaryo 1: Zorunlu alanları eksik bir form gönderme
Verilen kullanıcı kayıt formundadır Ne zaman kullanıcı "E-posta" alanını boş bırakıp "Gönder" seçeneğine tıklarsa Sonra sistem E-posta alanının altında satır içi "E-posta gereklidir" hata mesajını görüntüler Ve form gönderilmez
Sonra cümlesi hatanın yalnızca görüntülendiğini değil, nerede göründüğünü de belirtir ("E-posta alanının altında").
Senaryo 2: Bir metin alanındaki karakter sınırını aşma
Verilen kullanıcı 500 karakter sınırı olan "Biyografi" alanını dolduruyor Ne zaman kullanıcı 501 karakter girerse Sonra sistem daha fazla giriş yapılmasını engeller Ve bir mesajda "En fazla 500 karaktere izin verilir" yazısı görüntülenir
GWT ile Kontrol Listeleri ve Kullanım Örnekleri Karşılaştırması
Burada diğer bazı kabul kriteri türleri ve her birini ne zaman kullanabileceğiniz yer alır:
| Boyut | Ön Koşul-Eylem-Sonuç | Kural Odaklı Kontrol Listesi | Kullanım Senaryosu |
|---|---|---|---|
| Yapı | Ön koşul, Eylem, Sonuç | Kural maddelerinden oluşan liste | Akışları içeren numaralandırılmış adımlar |
| En uygun kullanım | Davranış senaryoları, BDD | İş kuralları, kullanıcı arayüzü özellikleri | Karmaşık, çok akışlı özellikler |
| Güçlü yönler | Test edilebilir, otomatikleştirilebilir, bağlam açısından zengin | Hızlı yazılır, kolay taranır | Kapsamlıdır, uç durumları kapsar |
| Sınırlamalar | Basit değişiklikler için ayrıntılı | Senaryo akışı yoktur, otomatikleştirilmesi zordur | Ağırdır, bakımı yavaştır |
| Hedef kitle | Geliştirici, kalite güvence, ürün ekibi | Ürün ekibi, tasarım, paydaşlar | Dış ekipler, uyumluluk |
| Kapsam | Tek davranış | Tüm özellik | Tüm özellik |
| Ayrıntı düzeyi | Üç ifade | Esnek | Ön koşullar, son koşullar, tetikleyiciler ve numaralandırılmış adımlar |
Düzenleyici uyumluluk amacıyla bir sistemi belgelemeniz veya sistemi harici bir tedarikçiye devretmeniz gerektiğinde kullanım senaryolarının en iyi sonucu verdiğini gördüm. Günlük sprint çalışmaları için ön koşul-eylem-sonuç yaklaşımı daha yalın ve hızlıdır.
Ön Koşul-Eylem-Sonuç için En İyi Uygulamalar
GWT'yi etkili bir şekilde kullanmanıza yardımcı olacak bazı en iyi uygulamalar şunlardır:
- Belirsiz veya muğlak ifadelerden kaçının: “Sonra sayfa hızlı yüklenir” demek yerine “Sonra arama sonuçları sayfası iki saniye içinde yüklenir” yazın. “Uygun” veya “ilgili” gibi sıfatları ölçülebilir değerlerle değiştirin. Test edemiyorsanız ifadeyi yeniden yazın.
- Senaryoları basit ve odaklanmış tutun: Senaryo başına tek davranış kuralını izleyin. Her senaryo tam olarak tek bir şeyi test etmelidir. Birden fazla eylemi veya sonucu birleştirdiğinizde hata ayıklaması ve bakımı zor test senaryoları oluşturursunuz. Bir senaryoda sonuç altında ikiden fazla ve ifadesi varsa, tek bir davranışı mı yoksa iki davranışı mı test ettiğinizi kendinize sorun.
- Üç arkadaş oturumu düzenleyin: Üç arkadaş oturumu, sprint başlamadan önce bir ürün sorumlusunun veya iş analistinin, bir geliştiricinin ve bir test uzmanının yaklaşan hikâyeleri birlikte gözden geçirdiği kısa ve odaklanmış bir konuşmadır. Yeniden çalışmayı önlemek için GWT ölçütlerini grup olarak yazar veya iyileştirirler.
- Terimlerde ve stilde tutarlılığı koruyun: Standart terimler seçin ve her hikâyede bunlara bağlı kalın. Bir senaryoda “müşteri”, diğerinde “kullanıcı” ifadesini kullanırsanız kafa karışıklığı yaratırsınız. Gerekirse küçük bir sözlük oluşturun. İfadelerinizde aynı cümle yapısını kullanın.
Yaygın Beş Karşıt Örüntü
Ön koşul-eylem-sonuç kabul ölçütlerini yazarken kaçınmanız gereken bazı yaygın hatalar şunlardır:
- Davranış yerine uygulama ayrıntılarını yazmak: “API çağrısı 200 durum kodu döndürdüğünde” gibi senaryolar teknik uygulamayı, kullanıcı davranışını değil, açıklar. Kullanıcının bakış açısından yeniden yazın: “Ürün kataloğu ana sayfada yüklendiğinde.” Teknik ayrıntıları test otomasyonu kodu için saklayın.
- Birden fazla senaryoyu tek bir senaryoda birleştirmek: Oturum açmayı, gezinmeyi ve ödeme işlemini tek bir blokta test eden senaryo, kabul kriteri değil, entegrasyon testidir. Her davranışı kendi senaryosuna ayırın. Böylece daha net sonuçlar elde eder ve hata ayıklamayı kolaylaştırırsınız.
- Olumsuz ve uç durum senaryolarını atlamak: Çevik geliştirme ekipleri genellikle başarılı akışı yazar ve işler ters gittiğinde ne olacağını unutur. Her başarılı senaryo için şu soruyu sorun: Girdi geçersizse ne olur? Ağ bağlantısı kesilirse ne olur? Veriler eksikse ne olur? Sorunları üretim ortamına ulaşmadan yakalamak için her hikâye başına en az bir olumsuz senaryo yazın.
- GWT'yi kabul edilebilir tek format olarak görmek: Davranışlar için GWT'yi, diğer her şey için kontrol listelerini kullanın. Düğme rengi değişiklikleri, metin güncellemeleri ve altyapı yapılandırması da dâhil olmak üzere her hikâyeyi ön koşul-eylem-sonuç formatına zorlayacak olursanız, bazı saçma sonuçlarla karşılaşırsınız (ör. “Ana sayfa mevcut olduğunda, kullanıcı ana sayfayı görüntülediğinde, başlık yazı tipi 16px olur.”).
- Senaryoları tek başına yazmak: GWT kriterlerini tek başınıza yazmayın. Formatın değeri, teşvik ettiği sohbetten gelir. Yazılım geliştirme başlamadan önce senaryolarınız en az iki farklı uzmanlık alanı tarafından tartışılmıyorsa, GWT'yi gerçek gücünün bir iş birliği formatı olduğu hâlde bir belgeleme formatı olarak kullanıyorsunuz demektir.
Sırada Ne Var?
Açık ön koşul-eylem-sonuç kabul kriterleri, başarılı projeler sunmanın yalnızca bir parçasıdır. Bu temeli ücretsiz DPM üyeliği ile güçlendirin; iyi tanımlanmış gereksinimleri daha sorunsuz teslimata ve daha güçlü sonuçlara dönüştürmenize yardımcı olan pratik şablonlara, uzman kaynaklarına ve kanıtlanmış çerçevelere erişim elde edin.
