⚖️ Deterministik vs Stokastik Test

Deterministik vs Stokastik Test: Deterministik bir test bir otomat makinesidir; stokastik bir test ise bir iş görüşmesidir — ve mekanizma gevşek değil, birebir örtüşür.

Deterministik bir test bir otomat makinesidir; stokastik bir test ise bir iş görüşmesidir — ve mekanizma gevşek değil, birebir örtüşür. Otomatta B4'e basarsın, HER seferinde aynı çikolata düşer; bozuk otomat tam da bunu YAPMAYANdır. Bir adaya aynı soruyu Pazartesi ve Cuma sorarsan farklı kelimelerle iki cevap alırsın — yine de iyi bir mülakatçı adil karar verir, çünkü ezberlenmiş tek bir cümleye değil bir rubriğe göre puan verir ("trade-off'ları söyledi mi? somut örnek verdi mi?"). Üzerinde durmaya değer soru şu: eğer cevap her koşuda meşru biçimde değişiyorsa, "test geçti" ne anlama gelir — ve hareketli bir hedefe nasıl assertion yazarsın? Çünkü "çıktı == beklenen" demeyi bırakıp "çıktı rubriği ≥ eşik karşılıyor mu?" demeye başladığın an, çıktının sabit olduğunu varsaymadan pass/fail yeniden ölçülebilir hale gelir. Java karşılaştırması: deterministik test assertEquals(expected, actual) gibidir — tek bir doğru değer; stokastik test ise bir code review'e daha yakındır — tek doğru satır yoktur, bir kontrol listesine göre puan verir ve birden fazla geçerli biçimi kabul edersin. QA açısından önemi: bu iki dünyayı karıştırmak AI test suite'lerinin çürüdüğü yerdir — bir chatbot'un tam string'ini assert etmek yeşil bir suite'i flaky ve işe yaramaz yapar; bir login yönlendirmesini "gözle kontrol etmek" ise sabit bir assertion'ın bedavaya yakaladığı şey için bir LLM çağrısı harcar. Bir kontrolün hangi dünyada yaşadığını bilmek ilk gerçek AI-QA becerisidir ve aşağıdaki lab, iki tarafı da kendin tekrar koşarak farkı hissetmeni sağlar.

İki Assertion, İki Dünya

Ayrım araçla ilgili değildir — çıktının sabit olup olmamasıyla ilgilidir. Deterministik kontrolün tek doğru cevabı vardır; eşitlik assert edersin ve her sapma bir bug'dır: URL, status kodu, hesaplanan toplam, şema yapısı. Stokastik kontrolün ise birden çok kabul edilebilir cevabı vardır; tek bir string'i assert edemezsin. Bunun yerine bir rubrik (doğruluk, alaka, güvenlik…) tanımlar, çıktıyı buna göre puanlar — genelde LLM-as-a-judge ile — ve "overall ≥ 4" gibi bir eşiğe göre geçirirsin. Olgun bir AI test planı ikisini birden tutar: sabit gerçeği olan her şey için deterministik "gate"ler ve bir modelin ürettiği her şey için olasılıksal "check"ler. İkisini karıştırmak, bir AI test suite'ini ya flaky (üretilen tam metni assert etmek) ya da kör (üretilen kaliteyi hiç kontrol etmemek) yapmanın en yaygın yoludur.

Aşağıdaki sol ve sağ paneli birkaç kez koştur. Playwright tarafı her koşuda birebir aynı PASS'i döndürür çünkü DOM durumu sabittir. Chatbot tarafı ise her koşuda farklı bir cevap döndürür — ve birinde model hiç var olmamış bir "30 gün / aynı gün iade" politikası uydurur: akıcı, kendinden emin ve yanlış. Tek string'lik bir assertion ya zararsız kelime değişikliklerinde flaky olurdu ya da tehlikeli halüsinasyonu tamamen kaçırırdı; bir rubrik puanı ise kötü koşuyu yakalar, iki iyi koşuyu kabul eder.

Deterministik (Playwright)

toHaveURL(/dashboard) — PASS

Stokastik (LLM-judge)

Bir login formunun geçerli kimlik bilgileriyle kullanıcıyı /dashboard'a yönlendirdiğini test etmek.

Bir müşteri hizmetleri chatbot'unun "kargom nerede?" sorusuna verdiği yanıtın kalitesini değerlendirmek.

Bir REST API'nin GET /users/1 çağrısına 200 ve doğru JSON şeması döndürdüğünü doğrulamak.

Bir RAG asistanının şirket politikası belgesinden ürettiği özetin halüsinasyon içerip içermediğini kontrol etmek.

Bir alışveriş sepeti toplamının 3 ürün eklendiğinde doğru tutarı gösterdiğini test etmek.

🎬 assertEquals Ölür, assertSemantic Doğar

Koşum 1: "İadeyi 30 gün içinde yapabilirsiniz"