Gerçek bir şirkette bir özellik tek başına doğmaz: önce iş gereksinimi yazılır, analiz edilir, epic'e bölünür, epic user story'lere ayrılır ve her story frontend ile backend tarafında ayrı ayrı hayata geçer. Test eden kişi bu zincirin tamamını okur. Burası o zincir.
Gerçek bir backlog baştan sona: 8 iş gereksinimi, 6 epic, 16 user story ve ayrı frontend/backend story'leri; hepsi test edilebilir kabul kriterleriyle.
Her halka bir öncekinin cevabıdır. Bir testin neden var olduğunu sorduğunda cevap yukarı doğru zincirde bulunur; bir gereksinimin karşılanıp karşılanmadığını sorduğunda cevap aşağı doğru bulunur. Test eden kişi bu zinciri iki yönde de yürüyebilmelidir.
Bu sayfada neler öğreneceksin
Bir özellik beş belgeden geçer — İş gereksinimi: İşin sistemden ne istediği. Çözümü değil ihtiyacı anlatır: "müşteri kendine ait bir hesapla alışveriş yapabilmeli". · Analiz dokümanı: İhtiyacın sisteme nasıl oturduğu: veri modeli, sipariş durum makinesi, iş kuralları. Ayrı bir belge
İş gereksinimleri — BR-01 Müşterinin kendine ait bir hesabı olmalı — Alışveriş yapan kişi kendini sisteme tanıtabilmeli; sepeti, adresleri ve siparişleri başkasınınkiyle karışmamalı. BR-02 Müşteri yalnızca gerçekten alınabilir ürünleri görmeli — Katalog ve arama sonuçları, satın
EP-01 Kimlik ve Oturum — Müşteri kendini sisteme tanıtabilsin, oturumu güvenle açılıp kapansın. US-01 Yeni müşteri hesap açar · US-02 Müşteri giriş yapar ve çıkar
EP-02 Katalog ve Arama — Müşteri satın alabileceği ürünleri bulabilsin, alamayacaklarıyla vakit kaybetmesin. US-03 Müşteri katalogu gezer, satıştan kalkan ürünü görmez · US-04 Müşteri ürün arar
EP-03 Sepet ve Kupon — Sepet stoğu gerçekten rezerve etsin, indirim sipariş anında yeniden doğrulansın. US-05 Müşteri sepete ürün ekler, stok rezerve edilir · US-06 Müşteri sepetteki adedi değiştirir · US-07 Müşteri kupon uygular, geçersiz kupon nedeniyle reddedilir · US-08 Sepette
EP-04 Sipariş ve Ödeme — Sipariş yalnızca anlamlı sırayla ilerlesin, stok ve para her adımda tutarlı kalsın. US-09 Müşteri sipariş verir, stok gerçekten düşer · US-10 Ödeme başarısız olur, sipariş ilerlemez · US-11 Ödemesiz sipariş kargolanamaz · US-12 İptal ve iade stoğu geri yükler
EP-05 Adres ve Yorumlar — Müşterinin her zaman kullanılabilir bir adresi olsun, yayına giren yorum denetimden geçsin. US-14 Yorum onaydan geçmeden ortalamaya girmez · US-15 Müşterinin her zaman tam bir varsayılan adresi vardır
EP-06 Veri Güvenliği ve Test Altyapısı — Müşteri verisi yalnızca sahibine açılsın, her test koşumu temiz bir durumdan başlasın. US-13 Bir müşteri başkasının siparişini göremez · US-16 Her koşum temiz durumdan başlar
Frontend ve backend story listesi — FE-01 Kayıt formu kullanıcıyı gönderim öncesinde uyarır · BE-01 Kayıt servisi hesabı tek ve güvenli biçimde oluşturur · FE-02 Arayüz oturumun açık mı kapalı mı olduğunu her zaman doğru gösterir · BE-02 Oturum servisi anahtarı yalnızca hak edene verir ve çıkışt
Test eden kişi bu zinciri nasıl yürür — Gereksinimi oku — sistem neyi vaat ediyor? — Story bir vaadin parçasıdır. Vaadi bilmeden yazılan test, kodun yaptığını tekrar eder; kodun yapması gerekeni değil. Analiz dokümanını aç — kural tam olarak nasıl tanımlı? — Veri modeli, sipariş durum makinesi ve iş
Sık Sorulan Sorular
Frontend ve backend story'leri ayrı yazmak neyi değiştirir?
Test edilecek yüzeyi ikiye ayırır. Bir kural arayüzde tutulup serviste tutulmayabilir: adet kutusu sıfırı reddederken servis aynı isteği kabul ediyor olabilir. Story'ler tek parça yazıldığında bu ayrım görünmez ve test genellikle yalnızca arayüzü sınar.
Frontend story'si neden "bir frontend geliştirici olarak" diye başlamıyor?
Çünkü o zaman user story olmaktan çıkar, kılık değiştirmiş bir task olur. Bir story her zaman kullanıcı gözünden yazılır ve değeri kullanıcıya akar; geliştirme zaten kullanıcı için yapılır. Frontend ve backend etiketi işin NEREDE yaşadığını söyler, KİMİN faydalandığını değil. Aktörü geliştirici yapmak, test edeni "bu kim için?" sorusundan koparır — oysa bir kabul kriterinin karşılanıp karşılanmadığı ancak o soruyla ölçülür.
Kabul kriterlerinde neden beklenen status kodu yazmıyor?
Sahada bir tester'ın eline gelen kriter iş dilindedir. Hangi kodun beklendiğine karar vermek, kriteri test case'e çevirmek test edenin işidir — hazır verildiğinde o beceri hiç gelişmez. Hangi endpoint'in hangi kodu döndürebileceği API sözleşmesinde zaten yazılıdır.
Epic ile user story arasındaki fark nedir?
Epic tek bir sprint'e sığmayan, birden çok story'yi bir arada tutan büyük parçadır ve tek başına test edilmez. User story ise müşteri için değer üreten en küçük parçadır; kabul kriterleri vardır ve uçtan uca test edilebilir. Burada her epic hangi iş gereksinimlerine hizmet ettiğini de söyler.
Business story'yi test ettim; frontend ve backend story'lerini ayrıca test etmem şart mı?
Business story'yi arayüzden uçtan uca test etmek, kuralın SERVİSTE de geçerli olduğunu kanıtlamaz. Arayüz sepet adedini sıfıra indirmene izin vermiyor olabilir ama aynı isteği doğrudan servise gönderdiğinde kabul ediliyor olabilir; bu durumda uçtan uca testin yeşildir ve kusur canlıda durur. Tersi de olur: servis kuralı doğru uygular, arayüz reddi kullanıcıya hiç göstermez ve işlem başarılı görünür. Bu yüzden aynı kural iki katmanda ayrı ayrı sınanır — bu tekrar değil, iki farklı iddiadır.