Prompt'larla kabul testleri: özellikleri senaryolara dönüştürün

Neden özellik prompt'ları eksik gereksinimlere dönüşür

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ı:

• Ana kullanıcı hedefi uçtan uca çalışır (mutlu yol).\n- En önemli hata modları temizce ele alınır (net hatalar, sessiz bozulma yok).\n- Özellik tutarlı davranır (aynı girdi, aynı sonuç).\n- Yanlışlıkla tehlikeli bir şey olmaz (başka bir kullanıcının erişimi, yinelenen eylemler).

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.

İyi bir kabul testi senaryosu nasıl görünür

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”).

İşe yarayan basit bir şekil

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.

Ekibinizin gerçekten kullanacağı bir senaryo formatı seçin

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ı nereye saklamalısınız ki kaybolmasın

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.

Adım adım: bir özellik prompt'unu 5–10 senaryoya dönüştürme

Ö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 yolu fazla düşünmeden nasıl yazarsınız

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:

• Kullanıcı doğru ekranı veya durumu doğru zamanda görür.
• Sistem doğru mesajı gösterir (başarı, onay veya sonraki yönerge).
• Veri kaydedilir (ne kaydedildiği, nasıl kaydedildiği değil).
• Kullanıcı devam edebilir (sonraki mantıklı aksiyon erişilebilir).

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.

Küçük ama etkili bir kenar durumu menüsü

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:

• Girdi problemleri (boş değerler, çok uzun, yanlış format, özel karakterler).
• Durum problemleri (izin yok, oturum süresi doldu, gereken veri eksik, hesap doğrulanmamış).
• Eşzamanlılık problemleri (çift tıklama iki kez gönderir, iki sekme aynı anda düzenliyor, spinner sonrası tekrarlar).
• Entegrasyon problemleri (zaman aşımı, sağlayıcı kapalı, kısmi başarısızlık, oran sınırlaması).
• Veri problemleri (çoğaltmalar, akış sırasında silinmiş kayıt, eskimiş veri, yuvarlama hataları).

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.

Uygulamalı örnek: bir özellik prompt'u sıkı bir senaryo setine dönüştürme

Ö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.

Mutlu yollar (2)

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

Kenar durumları (6)

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ı.

Kapsamı yüksek, test setini küçük tutma yolları

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:

• Smoke: Özelliğin uçtan uca çalıştığını kanıtlayan 1–2 senaryo.
• Regression: Önemli kurallar ve geçmiş hatalar için 2–6 senaryo.
• Exploratory: Tuhaf durumlar ve UX yargısı için birkaç “bunu dene” kontrolü.

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:

• Şimdi elle: metin, düzen, görsel durumlar, "kafa karıştırıcı" anlar.
• Yakında otomatize et: hesaplamalar, izinler, verinin doğru kaydedilmesi, kritik akışlar.
• Daha sonra otomatize et: nadir cihaz tuhaflıkları, alışılmadık tarayıcı zamanlamaları, üçüncü taraf hataları.

Senaryoları işe yaramaz yapan yaygın hatalar

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.

"Faydalı" vs "faydasız" kısa örnek

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 kabul etmeden önce hızlı kontrol listesi

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ş:

• Her senaryonun bir net ön koşulu ve bir ana sonucu var.
• Beklenen sonuçlar kullanıcının gördüğünü ve kaydedilen şeyi içerir.
• Roller önemliyse izinler kapsanmış (en az bir izinli ve bir izinsiz vaka).
• Önemli entegrasyonlar için en az bir gerçekçi hata modu dahil.
• Set 5–10 senaryo aralığında ve tekrar yok.

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.

Sonraki adımlar: prompt-to-tests iş akışınızı otomatize edin

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ışı:

• Her özellik prompt'unu 1 mutlu yol ve küçük bir kenar durumu seti dahil olmak üzere 5–10 senaryoya dönüştürün.
• Hızlıca gözden geçirip açık soruları düzeltin.
• Senaryoların tanımladığı şeyi uygulayın, geliştirme sırasında yeni bir gereksinim çıkarsa yeni bir senaryo ekleyin.
• Gözden geçirmede senaryoları kabul kontrol listesi olarak kullanın, belirsiz "görünüyor" yerine.
• Prompt değiştiğinde senaryoları güncelleyin, aksi halde "tamam" olan iş sessizce kayar.

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.