- Katılım
- 21 May 2023
- Mesajlar
- 505
- Tepki
- 17
- Puan
- 18
Teslim toplantısında müşteri "çalışsın yeter" der, geliştirici başını sallar ve ikisi de aynı şeyi kastettiğini sanır. Dosya teslim edildikten birkaç gün sonra ortaya çıkar ki müşteri için "çalışsın" ekranın hiç hata göstermemesi, geliştirici için ise yazılan testlerin geçmesiydi. İkisi de kendi tarafında haklı; sadece farklı bir şeyi onaylamışlar.
İşin özü basit: teslimden önce, gözlenebilir ve tek davranışlı kabul kriterleri yazılı hale getirilirse bu tartışmanın büyük kısmı baştan biter. Given-When-Then bunun için kullanılabilecek bir yazım biçimidir, tek yol değildir.
"Çalışsın" bir teknik tanım değil, bir beklenti özetidir. Müşteri bunu genelde "aklımdaki senaryo sorunsuz işlesin" diye anlar; geliştirici ise "üzerinde konuştuğumuz işlevi kod yerine getirsin" diye. Aradaki fark, teslim anına kadar hiç konuşulmamış olabilir.
Bu boşluk özellikle uç durumlarda büyür: boş bırakılan form, yavaş bağlantı, beklenmedik veri. Kabul kriteri, bu uç durumları teslimden önce isimlendirip yazıya döken araçtır.
Sorun ortaya çıktığında biri "eksik" der, öteki "zaten böyle teslim ettim" der; tartışma kriterin kendisi değil, kimin ne anladığı üzerinden ilerler.
Bir cümlenin kabul kriteri sayılabilmesi için üç şartı birlikte taşıması gerekir:
Bu üç şart karşılanmadan yazılan "iyi çalışsın", "kullanıcı dostu olsun" gibi ifadeler kabul kriteri değil, niyet beyanıdır. Aradaki fark şudur: niyet beyanı yorum ister, kabul kriteri ise sadece kontrol ister — birinin ekrana bakıp evet ya da hayır demesi yeterli olmalıdır.
Cucumber'ın resmî Gherkin referansına göre bu yapı üç bölümden oluşur: Given sistemi bilinen bir duruma getirir, When bir olayı veya kullanıcı eylemini tanımlar, Then gözlenebilir sonucu belirtir. Bu, Cucumber aracının kendi sözdizimidir; Agile Alliance'ın sözlüğüne göre ise aynı kalıp, bir kullanıcı hikâyesi için kabul testi yazımına rehberlik eden bir şablon olarak tanımlanır — zorunlu bir süreç değil, bir yazım biçimi. Ekibiniz aynı disiplini otomasyon aracı kurmadan, yalnızca yazılı kabul kriteri olarak da uygulayabilir.
Aşağıdaki örnek kurgusaldır, gerçek bir projeden alınmamıştır:
İkinci örnek de kurgusaldır: Diyelim ki kullanıcının girdiği kart bilgisi geçersiz olsun. Şu olduğunda ödeme adımını tamamlamaya çalışsın. O zaman sistem işlemi durdursun ve hatanın nedenini ekranda göstersin.
Kabul kriteri neyin doğru çalıştığını söyler; kapsam dışı ise neyin bu teslimde hiç ele alınmadığını. Hangi tarayıcı ve sürüm test edilecek, hangi veri hacminde denenecek, hangi ağ koşulu bu turun dışında — bunlar yazılmazsa herkes kendi varsayımıyla ilerler.
Örneğin "mobilde de çalışsın" cümlesi tek başına kapsam sayılmaz; hangi işletim sistemi sürümü, hangi ekran genişliği ve hangi tarayıcı motoru kastedildiği ayrıca yazılmalı. Yazılmayan her varsayım, teslim sonrasında birinin "bu da kapsamdaydı" demesine kapı açar.
Kapsamın nerede bittiği zaten ayrı bir tartışma başlığı: kabul kriteri işin neyi kapsadığını netleştirirken, müşteri "küçük bir revizyon" dediğinde o sınırın nasıl çizileceğini revizyon kapsamı yazısında ayrıca ele aldık.
Yazılı kriter tek başına yetmez; kimin hangi ortamda, hangi test verisiyle tıklayacağı da netleşmeli. Prod'a yakın bir test ortamı mı, yoksa geliştiricinin kendi makinesi mi kullanılacak? Gerçek veriye benzer örnek kayıtlar mı, yoksa boş bir veritabanı mı esas alınacak?
Onaylayan kişi teslimi fiilen alacak taraf olmalı; ekranı görmeyen birinin uzaktan "tamam" demesi, sonradan yeniden açılan bir onaydan farksızdır. Kaç tur revize edilip yeniden kontrol edileceği de baştan konuşulmalı, aksi halde her tur yeni bir tartışma başlatır.
Kabul kriterleri üzerinde anlaşıldıktan sonra bir sorun çıkarsa ilk soru şu olmalı: bu, yazılı bir kriteri karşılamıyor mu — o zaman hata; yoksa hiç yazılmamış yeni bir davranış mı isteniyor — o zaman yeni istek. Yazılı kriter bu ayrımı hızlandırır, olmayan kriter tartışmayı uzatır.
Kabul edilen işin ardından kaynak kod ve erişimlerin nasıl devredileceği ayrı bir konu; bunu teslim ve devir yazısında anlattık. Kabul kriterinin oturduğu genel çerçeve ise programlama hizmetinin ne olduğunu ve neyi kapsadığını anlatan hizmet tanıtım yazısıyla tamamlanıyor.
Kabul kriteri, "çalışsın" beklentisini gözlenebilir, tek davranışlı ve teslimden önce yazılmış cümlelere çevirmenin yoludur. Given-When-Then bunun için kullanışlı bir yazım biçimidir ama zorunlu bir araç değildir; ekip elle de aynı disiplinle yazabilir. Kapsam dışı ve kabul testi oturumu netleşmeden bırakılan kriter, teslimde yine aynı tartışmaya döner.
Son projenizde "tamam" demeyi hangi tek cümle netleştirdi?
Güncelleme: 21 Ağustos 2026. Cucumber'ın resmî Gherkin referansı ve Agile Alliance'ın Given-When-Then sözlük tanımı canlı olarak kontrol edildi.
İşin özü basit: teslimden önce, gözlenebilir ve tek davranışlı kabul kriterleri yazılı hale getirilirse bu tartışmanın büyük kısmı baştan biter. Given-When-Then bunun için kullanılabilecek bir yazım biçimidir, tek yol değildir.
Aynı cümle, teslimde iki farklı anlama gelir
"Çalışsın" bir teknik tanım değil, bir beklenti özetidir. Müşteri bunu genelde "aklımdaki senaryo sorunsuz işlesin" diye anlar; geliştirici ise "üzerinde konuştuğumuz işlevi kod yerine getirsin" diye. Aradaki fark, teslim anına kadar hiç konuşulmamış olabilir.
Bu boşluk özellikle uç durumlarda büyür: boş bırakılan form, yavaş bağlantı, beklenmedik veri. Kabul kriteri, bu uç durumları teslimden önce isimlendirip yazıya döken araçtır.
Sorun ortaya çıktığında biri "eksik" der, öteki "zaten böyle teslim ettim" der; tartışma kriterin kendisi değil, kimin ne anladığı üzerinden ilerler.
Kabul kriterinin üç şartı
Bir cümlenin kabul kriteri sayılabilmesi için üç şartı birlikte taşıması gerekir:
- Gözlenebilir: Ekranda, veritabanında veya API yanıtında birinin "oldu" ya da "olmadı" diyebileceği somut bir sonuç olmalı.
- Tek davranış: Bir kriterde "ve" ile bağlanmış birden fazla farklı davranış olmamalı; her biri ayrı satır olsun.
- Önceden yazılı: Teslimden sonra hatırlanan değil, işe başlamadan önce üzerinde anlaşılan bir cümle olmalı.
Bu üç şart karşılanmadan yazılan "iyi çalışsın", "kullanıcı dostu olsun" gibi ifadeler kabul kriteri değil, niyet beyanıdır. Aradaki fark şudur: niyet beyanı yorum ister, kabul kriteri ise sadece kontrol ister — birinin ekrana bakıp evet ya da hayır demesi yeterli olmalıdır.
Given-When-Then'i Türkçe kurmak: iki kurgusal örnek
Cucumber'ın resmî Gherkin referansına göre bu yapı üç bölümden oluşur: Given sistemi bilinen bir duruma getirir, When bir olayı veya kullanıcı eylemini tanımlar, Then gözlenebilir sonucu belirtir. Bu, Cucumber aracının kendi sözdizimidir; Agile Alliance'ın sözlüğüne göre ise aynı kalıp, bir kullanıcı hikâyesi için kabul testi yazımına rehberlik eden bir şablon olarak tanımlanır — zorunlu bir süreç değil, bir yazım biçimi. Ekibiniz aynı disiplini otomasyon aracı kurmadan, yalnızca yazılı kabul kriteri olarak da uygulayabilir.
Aşağıdaki örnek kurgusaldır, gerçek bir projeden alınmamıştır:
Kurgusal örnek — form gönderimi' Alıntı:
İkinci örnek de kurgusaldır: Diyelim ki kullanıcının girdiği kart bilgisi geçersiz olsun. Şu olduğunda ödeme adımını tamamlamaya çalışsın. O zaman sistem işlemi durdursun ve hatanın nedenini ekranda göstersin.
Kapsam dışını da yazıya dökmek gerekir
Kabul kriteri neyin doğru çalıştığını söyler; kapsam dışı ise neyin bu teslimde hiç ele alınmadığını. Hangi tarayıcı ve sürüm test edilecek, hangi veri hacminde denenecek, hangi ağ koşulu bu turun dışında — bunlar yazılmazsa herkes kendi varsayımıyla ilerler.
Örneğin "mobilde de çalışsın" cümlesi tek başına kapsam sayılmaz; hangi işletim sistemi sürümü, hangi ekran genişliği ve hangi tarayıcı motoru kastedildiği ayrıca yazılmalı. Yazılmayan her varsayım, teslim sonrasında birinin "bu da kapsamdaydı" demesine kapı açar.
Kapsamın nerede bittiği zaten ayrı bir tartışma başlığı: kabul kriteri işin neyi kapsadığını netleştirirken, müşteri "küçük bir revizyon" dediğinde o sınırın nasıl çizileceğini revizyon kapsamı yazısında ayrıca ele aldık.
Kabul testi oturumunu kim, nasıl yürütür?
Yazılı kriter tek başına yetmez; kimin hangi ortamda, hangi test verisiyle tıklayacağı da netleşmeli. Prod'a yakın bir test ortamı mı, yoksa geliştiricinin kendi makinesi mi kullanılacak? Gerçek veriye benzer örnek kayıtlar mı, yoksa boş bir veritabanı mı esas alınacak?
Onaylayan kişi teslimi fiilen alacak taraf olmalı; ekranı görmeyen birinin uzaktan "tamam" demesi, sonradan yeniden açılan bir onaydan farksızdır. Kaç tur revize edilip yeniden kontrol edileceği de baştan konuşulmalı, aksi halde her tur yeni bir tartışma başlatır.
Teslim sonrası: hata mı, yeni istek mi?
Kabul kriterleri üzerinde anlaşıldıktan sonra bir sorun çıkarsa ilk soru şu olmalı: bu, yazılı bir kriteri karşılamıyor mu — o zaman hata; yoksa hiç yazılmamış yeni bir davranış mı isteniyor — o zaman yeni istek. Yazılı kriter bu ayrımı hızlandırır, olmayan kriter tartışmayı uzatır.
Kabul edilen işin ardından kaynak kod ve erişimlerin nasıl devredileceği ayrı bir konu; bunu teslim ve devir yazısında anlattık. Kabul kriterinin oturduğu genel çerçeve ise programlama hizmetinin ne olduğunu ve neyi kapsadığını anlatan hizmet tanıtım yazısıyla tamamlanıyor.
Özetle
Kabul kriteri, "çalışsın" beklentisini gözlenebilir, tek davranışlı ve teslimden önce yazılmış cümlelere çevirmenin yoludur. Given-When-Then bunun için kullanışlı bir yazım biçimidir ama zorunlu bir araç değildir; ekip elle de aynı disiplinle yazabilir. Kapsam dışı ve kabul testi oturumu netleşmeden bırakılan kriter, teslimde yine aynı tartışmaya döner.
Son projenizde "tamam" demeyi hangi tek cümle netleştirdi?
Güncelleme: 21 Ağustos 2026. Cucumber'ın resmî Gherkin referansı ve Agile Alliance'ın Given-When-Then sözlük tanımı canlı olarak kontrol edildi.
Dijital Dünyanıza Yön Veren Pusula
