📋 Test Case Üretimi

Test Case Üretimi: Claude'un eksik bir user story'den test case üretmesi, ölçüleri eksik bir kat planından inşaat yapan bir müteahhite benzer — mekanizma birebirdir: müteahhit bi

Claude'un eksik bir user story'den test case üretmesi, ölçüleri eksik bir kat planından inşaat yapan bir müteahhite benzer — mekanizma birebirdir: müteahhit bir duvarın uzunluğunu tahmin EDEBİLİR (istatistiksel olarak olası bir sayı), ama bina araziye sığmayabilir. Üzerinde durulmaya değer soru şu: Claude saniyeler içinde 20 test case üretebiliyorsa, ondan istediğin İLK şey neden testleri yazması değil, neyin eksik olduğunu listelemesi olmalı? Çünkü çoğu user story sınır durumlar ve eşik değerler konusunda sessizdir — boşlukları sordurmayı atlarsan Claude onları kendi eğitim verisinden gelen varsayılanlarla doldurur, senin ürününün gerçek kuralıyla değil. Java karşılaştırması: bu, Javadoc'u olmayan bir interface metoduna karşı JUnit testi yazmak gibidir — bir tahmini derleyebilirsin ama kontratın gerçek ön/son koşulları olmadan gereksinimi değil, kendi varsayımını test ediyorsundur. QA tarafındaki bedel: Claude'un sessizce doldurduğu varsayımlar üzerine kurulan bir test seti CI'da yeşil geçer ama asıl önemli kabul kriterini kaçırır — Giriş sekmesindeki oracle probleminin aynı sahte-güven tuzağı, bu sefer test tasarım aşamasında değil story-alım aşamasında.

Doğrudan test istemek yerine iki adımlı bir teknik kullan. Birinci adım: user story ve kabul kriterlerini yapıştır, Claude'dan belirsiz veya eksik olan HER kuralı LİSTELEMESİNİ iste — henüz hiçbir test istemiyorsun. İkinci adım: bu listeyi product owner'ına veya ekibine götür, gerçek ve onaylanmış cevaplar al. Ancak o zaman test case iste, Claude'a SADECE onaylanmış kuralları kullanmasını açıkça söyleyerek. Bu sıralama, tek seferlik bir üretimi, oracle boşluğunun sessizce doldurulmadan önce yüzeye çıktığı kontrollü, iki aşamalı bir konuşmaya dönüştürür.

Akıl yürütme: neden düz bir madde listesi yerine özellikle Gherkin'de üretilsin? Given/When/Then, her senaryo için açık bir ön koşul, eylem ve beklenen sonuç üçlüsünü zorunlu kılar — bu da tam olarak Claude'un belirsiz çıktıdan kaçınmak için doldurması gereken şekildir; format kendisi spesifiklik için zorlayıcı bir mekanizmaya dönüşür, tıpkı güçlü tipli bir metod imzasının kod derlenmeden önce her parametreyi vermeni zorlaması gibi.

Prompt Mühendisliği sekmesindeki Prompt Lab'da öğrendiğin 4 bileşeni burada da kullan: rol = "kıdemli QA mühendisi", bağlam = user story + kabul kriterleri, format = "Gherkin", kısıt = "sadece onaylanmış kurallara dayan".

Adım Adım: User Story'den Gherkin'e

User story ve kabul kriterleri prompt'a bağlam olarak yapıştırılır.

Önce belirsizlikleri sordur

Test yazmadan önce Claude'a story'deki belirsiz veya eksik HER kuralı listelettirilir.

Gerçek belirsizlikler PO/ekiple netleştirilir — Claude'un uydurduğu bir varsayımla değil.

SADECE onaylanmış kurallara dayanan N adet Given/When/Then senaryosu istenir.

Oracle olarak incele

Her senaryo, kabul kriterleri listesine karşı SEN tarafından kontrol edilir — akıcı Gherkin sözdizimi kapsamın doğru olduğunun kanıtı değildir.

User story'den güvenilir Gherkin senaryosu üretme akışını doğru sıraya diz.

User story + kabul kriterlerini bağlam olarak yapıştır