Her özellik isteğini 5–10 net senaryoya dönüştürerek prompt'lardan kabul testleri yazmayı öğrenin; mutlu yolları ve gerçekçi kenar durumları kapsayın, şişkin test paketleri oluşturmadan güven sağlayın.
Sohbet tarzı özellik prompt'ları bir konuşma gibi okunduğu için netmiş gibi hissedilir. Ancak birkaç dostane cümlenin içine seçimler, kurallar ve istisnalar sıkıştırılmış olur. Boşluklar, biri gerçekten özelliği kullanana kadar görünmez.
Çoğu prompt sessizce varsayımlara dayanır: işlemi kim yapmaya yetkili, "başarı" ne anlama geliyor (kaydedildi, gönderildi, yayınlandı, ödendi), veri eksik olduğunda ne olur ve bir şey başarısız olunca kullanıcı ne görmeli. Ayrıca "yeterince hızlı" veya "yeterince güvenli" gibi bulanık standartları da saklarlar.
Belirsizlik genellikle geç dönemde hata ve yeniden iş olarak ortaya çıkar. Bir geliştirici prompt'un ne anlama geldiğini düşündüğü şekilde inşa eder, bir gözden geçiren doğru göründüğü için onaylar ve sonra kullanıcılar garip durumlara takılır: yinelenen gönderimler, zaman dilimleri, kısmi veriler veya izin uyuşmazlıkları. Bunları sonra düzeltmek daha pahalı olur çünkü genellikle kodu, UI metnini ve bazen veri modelini etkiler.
Kalite büyük test paketleri gerektirmez. Kalite demek, normal kullanımlarda ve öngörülebilir baskı altında özelliğe güvenebilmek demektir. İyi seçilmiş küçük bir senaryo seti, yüzlerce test olmadan bu güveni verir.
Prompt ile oluşturulan özellikler için pratik bir kalite tanımı:
Prompt'ları kabul senaryolarına dönüştürmenin amacı budur: belirsiz bir isteği alın ve gizli kuralları erken ortaya çıkaran 5–10 kontrol haline getirin. Her şeyi test etmeye çalışmıyorsunuz. Gerçekten olan hataları yakalamaya çalışıyorsunuz.
Hızlı bir prompt'tan inşa ediyorsanız ve Koder.ai gibi bir vibe-coding araçta çalışıyorsanız, çıktı eksiksiz görünebilir ama kenar kuralları atlıyor olabilir. Sıkı bir senaryo seti bu kuralların henüz değişiklikler ucuzken adlandırılmasını sağlar.
Bir kabul testi senaryosu, kullanıcı eyleminin ve görmesi gereken sonucun kısa, yalın-dil açıklamasıdır.
Yüzeyde kalın: kullanıcının ne yapabileceği ve ürünün ne gösterdiği veya değiştirdiği. Veritabanı tabloları, API çağrıları, arka plan işler veya hangi çatının kullanıldığı gibi iç detaylardan kaçının. Bu detaylar sonra önemli olabilir ama senaryoları kırılgan ve uzlaşması zor hale getirir.
İyi bir senaryo ayrıca bağımsızdır. Yarın temiz bir ortamda çalıştırması kolay olmalıdır; başka bir senaryonun önce çalışmış olmasına güvenmemelidir. Eğer bir senaryo önceki duruma bağlıysa, bunu kurulumda açıkça belirtin (örneğin, “kullanıcının zaten aktif bir aboneliği var”).
Birçok ekip, senaryoları gereksiz ayrıntıya boğmadan netlik zorlaması yaptığı için Given–When–Then kullanır.
Bir senaryo genellikle bir hedef, net bir başlangıç durumu, somut bir eylem ve görünür bir sonuç olduğunda “tamam” sayılır. İkili olmalıdır: ekipteki herhangi biri çalıştırdıktan sonra “geçti” veya “kaldı” diyebilmelidir.
Örnek: “Giriş yapmış ve kaydedilmiş ödeme yöntemi olmayan bir kullanıcı verildiğinde, Pro'yu seçip ödemeyi onayladığında, başarı mesajı görür ve hesabında planın Pro olarak gösterildiğini görür.”
Eğer sohbet-öncelikli bir oluşturucuda (ör. Koder.ai) inşa ediyorsanız, aynı kuralı koruyun: oluşturulan uygulamanın davranışını test edin (kullanıcının deneyimi), platformun kodu nasıl ürettiğini değil.
En iyi format, insanların yazıp okuyacağı formattır. Eğer ekibin yarısı uzun anlatılar kullanıp diğer yarısı kısa maddeler yazarsa, yazım farkları, tekrarlar ve kelimecilik tartışmaları nedeniyle kalite yerine sürtüşme elde edersiniz.
Given–When–Then, özellik etkileşimli ve durumluysa iyi çalışır. Birçok benzer durumda giriş-çıkış kuralları varsa basit bir tablo daha kolay taranır.
Ekip bölünmüşse, 30 gün boyunca bir format seçin ve sonrasında düzeltin. Gözden geçirenler sürekli “başarı ne demek?” diye soruyorsa, Given–When–Then'e doğru ilerlemek genelde işaret eder. Senaryolar uzamaya başladıysa tablo daha kolay olabilir.
Ne seçerseniz seçin, standardize edin. Aynı başlıkları, aynı zamanı ve aynı detay seviyesini kullanın. Ayrıca neyi dahil etmeyeceğinize de anlaşın: piksel-hassas UI detayları, iç uygulama, veritabanı konuşmaları. Senaryolar kullanıcının ne gördüğünü ve sistemin ne garanti ettiğini tanımlamalıdır.
Senaryoları işin zaten yapıldığı yere koyun ve özelliğe yakın tutun.
Yaygın seçenekler: ürün kodunun yanında saklamak, ticket'ların altında “Acceptance scenarios” bölümü açmak veya özellik başına bir sayfa olacak paylaşılan bir doküman alanında tutmak. Koder.ai kullanıyorsanız, Planning Mode'da senaryoları da tutarak bunları build geçmişi, snapshot'lar ve rollback noktalarıyla birlikte saklayabilirsiniz.
Anahtar; aranabilir olmaları, tek kaynak olması ve geliştirme “başladı” sayılmadan önce senaryoları zorunlu kılmaktır.
Önce prompt'u bir kullanıcı hedefi ve net bir bitiş çizgisi olarak yeniden yazın. Bir cümleyle hedefi (kim ne istiyor) yazın, sonra doğrulanabilir 2–4 başarı kriteri ekleyin. Görünür bir sonucu işaret edemiyorsanız, henüz bir testiniz yok demektir.
Sonra prompt'u girdiler, çıktılar ve kurallar olarak parçalayın. Girdiler kullanıcının sağladığı veya seçtiği şeylerdir. Çıktılar sistemin gösterdiği, kaydettiği, gönderdiği veya engelledikleridir. Kurallar arasında satır aralarındaki “yalnızca eğer” ve “zorunlu” ifadeleri bulunur.
Sonra özelliğin çalışabilmesi için neye bağımlı olduğunu kontrol edin. İşte senaryo boşluklarının saklandığı yer: gerekli veriler, kullanıcı rolleri, izinler, entegrasyonlar ve sistem durumları. Örneğin Koder.ai'de bir uygulama inşa ediyorsanız, eylemden önce kullanıcının giriş yapması, proje oluşturmuş olması veya plan/erişim şartlarını karşılaması gerekip gerekmediğini belirtin.
Şimdi özelliğin çalıştığını kanıtlayan en küçük senaryo setini yazın: genellikle 1–2 mutlu yol ve 4–8 kenar durumu. Her senaryoyu tek bir başarısızlık nedenine odaklayın.
Seçilecek iyi kenar durumları (sadece prompt'a uyanlar): eksik veya geçersiz girdi, izin uyuşmazlığı, “zaten gönderildi” gibi durum çatışmaları, zaman aşımı gibi dış bağımlılık sorunları ve kurtarma davranışı (net hatalar, güvenli yeniden deneme, kısmi kayıt yok).
Bitirirken hızlıca “ne ters gidebilir?” kontrolü yapın. Sessiz hatalar, kafa karıştırıcı mesajlar ve sistemin yanlış veri oluşturabileceği yerleri arayın.
Mutlu yol, her şeyin doğru gittiği en kısa, en normal yoldur. Onu kasıtlı olarak sıkıcı tutarsanız, daha sonra kenar durumlarını tespit etmek kolaylaşır.
Varsayılan kullanıcıyı ve varsayılan veriyi adlandırın. "Kullanıcı" demek yerine gerçek bir rol kullanın: “Giriş yapmış, e-postası doğrulanmış müşteri” veya “faturalamayı düzenleme iznine sahip Admin.” Ardından mantıklı en küçük örnek veriyi tanımlayın: bir proje, listede bir öğe, bir kaydedilmiş ödeme yöntemi. Bu, senaryoları somut kılar ve gizli varsayımları azaltır.
Başarıya giden en kısa yolu ilk yazın. Opsiyonel adımları ve alternatif akışları çıkarın. Örneğin “Görev oluştur” özelliği için mutlu yol, oluşturma sonrası filtreleme, sıralama veya düzenleme adımlarını içermemelidir.
Bunu sıkı tutmanın basit bir yolu dört şeyi onaylamaktır:
Sonra sadece bir değişkeni değiştiren bir varyant ekleyin. En çok kırılma ihtimali olan değişkeni seçin, örneğin "başlık uzun" veya "kullanıcının mevcut öğesi yok" gibi ve gerisini aynı bırakın.
Örnek: prompt'unuz “Kaydetme sonrası 'Snapshot oluşturuldu' toast'ı ekle” diyorsa, mutlu yol: kullanıcı Create Snapshot'e tıklar, yükleniyor durumu görünür, “Snapshot oluşturuldu” görür ve snapshot doğru zaman damgasıyla listede görünür. Tek değişkenli varyant, boş bir isimle aynı adımlar ama net bir varsayılan adlandırma kuralı gösterir.
Kenar durumları çoğu hatanın saklandığı yerdir; büyük bir test paketi gerekmez. Her özellik prompt'u için gerçek davranışa ve gerçek hata modlarına uyan küçük bir seçim yapın.
Yaygın kategoriler:
Her özellik her kategoriye ihtiyaç duymaz. Bir arama kutusu girdiye odaklanırken bir ödeme akışı entegrasyon ve veriye odaklanır.
Riskle eşleşen kenar durumlarını seçin: başarısızlığın maliyeti yüksekse (para, güvenlik, gizlilik), sık görülüyorsa, kırılması kolay bir akışsa, geçmişte hata olmuşsa veya sonradan tespit edilmesi zor bir sorun ise bu senaryolar önceliklidir.
Örnek: “kullanıcı abonelik planını değiştirir” için sık işe yarayan senaryolar: ödeme sırasında oturumun süresinin dolması, "Onayla"ya çift tıklama ve ödeme sağlayıcısı zaman aşımıyla planın değişmeden kalıp net bir mesaj gösterilmesi.
Örnek özellik prompt'u (düz dil):
“Bir şeyi bozduğumda, uygulamamı önceki bir snapshot'a geri almak istiyorum, böylece son çalışan sürüm tekrar canlı olur.”
Aşağıda kompakt bir senaryo seti var. Her senaryo kısa ama bir sonucu sabitliyor.
S1 [Zorunlu] En son snapshot'a geri al
Given giriş yapmışım ve uygulamaya sahibim
When “Rollback” seçip onaylıyorum
Then uygulama önceki snapshot'ı dağıtır ve uygulama durumu aktif sürüm olarak yeni versiyonu gösterir
S2 [Zorunlu] Belirli bir snapshot'a geri al
Given uygulamamın snapshot listesini görüntülüyorum
When snapshot “A”yı seçip rollback'i onaylıyorum
Then snapshot “A” aktif sürüm olur ve ne zaman oluşturulduğunu görebilirim
S3 [Zorunlu] İzin yok (auth)
Given giriş yapmışım ama bu uygulamaya erişimim yok
When rollback yapmayı deniyorum
Then erişim hatası görüyorum ve rollback hiç başlamaz
S4 [Zorunlu] Snapshot bulunamadı (doğrulama)
Given bir snapshot ID'si yok (veya silinmiş)
When ona rollback yapmayı deniyorum
Then net bir “snapshot bulunamadı” mesajı alırım
S5 [Zorunlu] Çift gönderim (çoğaltmalar)
Given “Confirm rollback”e hızlıca iki kez tıklıyorum
When ikinci istek gönderiliyor
Then yalnızca bir rollback çalışır ve tek bir sonuç görürüm
S6 [Zorunlu] Dağıtım başarısızlığı (hatalar)
Given rollback başlıyor
When dağıtım başarısız oluyor
Then şu anki aktif sürüm yayında kalır ve hata gösterilir
S7 [İyi-olur] Zaman aşımı veya bağlantı kopması
Given bağlantım rollback sırasında kopuyor
When sayfayı yeniliyorum
Then rollback'in hala çalışıp çalışmadığını veya bitip bitmediğini görebilirim
S8 [İyi-olur] Zaten o snapshot üzerinde
Given snapshot “A” zaten aktif
When snapshot “A”ya rollback yapmayı deniyorum
Then hiçbir şeyin değişmediği söylenir ve yeni bir dağıtım başlamaz
Her senaryo üç soruyu cevaplar: kim yapıyor, ne yapıyor ve sonrasında ne doğru olmalı.
Hedef “her şeyi test etmek” değil. Hedef, kullanıcıya zarar verecek riskleri kapsamak, kimsenin çalıştırmadığı bir senaryo yığını oluşturmamaktır.
Pratik bir hile senaryoları nasıl kullanacağınızı etiketlemektir:
Her farklı risk için bir senaryo ile sınırlayın. Eğer iki senaryo aynı nedenle başarısız oluyorsa, muhtemelen yalnızca birine ihtiyacınız vardır. “Geçersiz e-posta formatı” ve “e-posta eksik” farklı risklerdir. Ama “Adım 1'de eksik e-posta” ve “Adım 2'de eksik e-posta” aynı kural ise bunlar tekrardır.
Ayrıca birçok senaryoda UI adımlarını tekrarlamaktan kaçının. Tekrarlanan parçaları kısa tutun ve değişen kısma odaklanın. Bu, Koder.ai gibi sohbet tabanlı araçlarda UI değiştikçe iş kuralı sabit kaldığında daha da önemlidir.
Son olarak şimdi neyi kontrol edeceğinize vs. daha sonra neyi kontrol edeceğinize karar verin. Bazı kontroller başlangıçta elle, sonra otomatize edilmek üzere daha uygundur:
Bir senaryo sizi sürprizlerden korumalı, ekip nasıl inşa edeceğini tarif eden bir teknik kontrol listesi olmamalıdır.
En yaygın hata kullanıcı hedefini teknik bir yapılacak listesine dönüştürmektir. Senaryo "API 200 döner" veya "tablo X kolonu Y'ye sahip" diyorsa, tek bir tasarıma kilitlenir ve yine de kullanıcının ihtiyacını kanıtlamaz.
Diğer bir problem birden fazla hedefi tek uzun senaryoda birleştirmektir. Bu bir yolculuk gibi okunur ama başarısız olduğunda nedenini kimse bilemez. Bir senaryo bir soruya yanıt vermelidir.
Gerçek olmayan ama havalı görünen kenar durumlarına dikkat edin. "Kullanıcının 10 milyon projesi var" veya "ağ her 2 saniyede kopuyor" genelde üretimle uymaz ve yeniden üretmesi zordur. Kurulumunu dakikalar içinde yapabileceğiniz kenar durumlarını seçin.
Ayrıca "çalışıyor", "hata yok" veya "başarıyla tamamlandı" gibi belirsiz sonuçlardan kaçının. Bu kelimeler doğrulanması gereken kesin sonucu gizler.
Koder.ai'nın “kaynak kodu dışa aktarma” özelliği gibi bir şey inşa ediyorsanız, zayıf senaryo şudur: “Kullanıcı export'a tıkladığında sistem repoyu zipler ve 200 döner.” Bu uygulamayı test eder, vaat edilen sonucu değil.
Daha iyi bir senaryo: “İki snapshot'ı olan bir proje verildiğinde, kullanıcı export yaptığında, indirme geçerli snapshot'ın kodunu içerir ve export kaydı kim dışa aktardığını ve ne zaman yaptığını kaydeder.”
"Hayır" yollarını da unutmayın: “Export izni olmayan bir kullanıcı verildiğinde, export seçeneği gizlenir veya engellenir ve hiçbir export kaydı oluşturulmaz.” Tek satır hem güvenliği hem veri bütünlüğünü korur.
Senaryo setini “tamam” saymadan önce, onu seçici bir kullanıcı ve bir veritabanı gibi okuyun. Test başlamadan önce neyin doğru olması gerektiğini veya “başarı”nın ne demek olduğunu söyleyemiyorsanız, hazır değildir.
İyi bir set küçük ama spesifiktir. Yazmayan birine verip aynı sonuçları alabilmelisiniz.
Onay (veya iade) için hızlı geçiş:
Eğer senaryoları sohbet tabanlı bir oluşturucuda (Koder.ai) üretiyorsanız, aynı standardı uygulayın: belirsiz “beklendiği gibi çalışır” ifadeleri yok. Gözlemlenebilir çıktılar ve kaydedilen değişiklikleri isteyin, sonra sadece doğrulanabilecekleri onaylayın.
Senaryo yazmayı işin bir adımı yapın, sonradan temizleme işi değil.
Uygulamayı değiştirmek hala ucuzken senaryoları uygulamadan önce yazın. Bu, ekibi zor soruları erken cevaplamaya zorlar: “başarı” ne demek, kötü girdi durumunda ne olur ve şu an neyi desteklemeyeceksiniz.
Senaryoları “done” tanımınız yapın. Ürün amacını belirler, QA risk düşüncesini sahiplenir ve mühendislik uygulanabilirliği sağlar. Üçü de aynı senaryo setini okuyup anlaşabildiğinde, "tamamlandı" görünüp kabul edilemez bir şey göndermeden kaçınırsınız.
Çoğu ekipte işe yarayan iş akışı:
Koder.ai'de (koder.ai) inşa ediyorsanız, önce senaryoları taslaklayıp sonra Planning Mode ile her senaryoyu ekranlara, veri kurallarına ve kullanıcı-görünür sonuçlara bağlamak üretim öncesi haritalama yapmanıza yardımcı olur.
Riskli değişiklikler için, başlamadan önce bir snapshot alın. Yeni bir kenar durum çalışan akışı bozarsa, rollback bir günü yan etkileri çözmekle uğraşmaktan kurtarabilir.
Senaryoları özellik isteğiyle (veya aynı ticket içinde) yakın tutun ve onları sürümlenmiş gereksinimler gibi ele alın. Prompt'lar evrildiğinde, senaryo seti de onlarla birlikte evrilmeli; yoksa "tamamlandı" sessizce kayar.
Başlangıç için tek cümlelik bir hedef ve bitiş çizgisi yazın.
Sonra prompt'u şu parçalara ayırın:
Bundan sonra 1–2 mutlu yol ve gerçek risklere uyan 4–8 kenar durumu yazın (izinler, yinelenen gönderimler, zaman aşımı, eksik veri).
Çünkü prompt'lar varsayımları saklar. Bir prompt "kaydet" diyebilir ama bunun taslak mı yayın mı olduğunu, hata olduğunda ne olup bittiğini veya kimin yapmaya yetkili olduğunu tanımlamayabilir.
Senaryolar, tekrar göndermeler, izin uyuşmazlıkları veya tutarsız sonuçlar gibi hataları göndermeden önce kuralları isimlendirmenizi sağlar.
Given–When–Then etkileşimli, durumlu özelliklerde iyi çalışır.
Pek çok benzer kural kontrolünüz olduğunda basit bir giriş/çıkış tablosu daha okunur olur.
Bir ay boyunca tek bir format seçin ve standartlaştırın (aynı zaman kipini, aynı detay seviyesini kullanın). En iyi format, ekibinizin gerçekten kullanacağı formattır.
İyi bir senaryo şunlardır:
Herhangi bir ekip üyesi çalıştırıp sonucu tartışmasız kabul edebilirse senaryo "tamamlanmıştır".
Gözlemlenebilir davranışa odaklanın:
Uygulama detaylarını koymaktan kaçının: veritabanı tabloları, API yanıt kodları, arka plan işler veya çerçeveler. Bu detaylar sık değişir ve kullanıcının gerçekten istediğini kanıtlamaz.
Her şeyin doğru gittiği en sıkıcı, normal yolu yazın:
Sonra dört şeyi doğrulayın: doğru ekran/durum, net başarı mesajı, verinin kaydedildiği ve kullanıcının sonraki makul aksiyona devam edebildiği.
Risk ve sıklığa göre kenar durumları seçin:
Her farklı risk için bir senaryo hedefleyin; tüm varyasyonları test etmeye çalışmayın.
Güvenli ve anlaşılır tutun:
Bir hata senaryosu sistemin veriyi bozmadığını veya kullanıcıyı yanılttığını kanıtlamalıdır.
Koder.ai çıktısını diğer uygulamalar gibi ele alın: kullanıcının deneyimini test edin, kodun nasıl üretildiğini değil.
Pratik yaklaşım:
İşi zaten yaptığınız yerde saklayın ve tek bir gerçek kaynağı tutun:
Koder.ai kullanıyorsanız, Planning Mode içinde senaryoları tutun ki build geçmişiyle ilişkilensin. En önemlisi: geliştirme başlamadan önce senaryoları zorunlu kılın.
