Ünite 5 / 12

Test Üretimi ve Kalite Güvencesi

Kazanimlar:

  • AI ile birim testi, kenar durum vakaları ve kapsam boşluğu analizi üretebilme
  • Testin beklentilerini kodun mevcut davranışına değil, spesifikasyona göre yazdırabilme
  • Bir testin gerçekten koruduğunu hata enjekte ederek sınayabilme

Test yazmak, çoğu geliştiricinin ertelediği ama en çok değer üreten işlerden biridir. İyi bir test takımı (test suite), kodun beklendiği gibi çalıştığının kanıtı ve gelecekteki değişikliklerin can simididir. Sorun, test yazmanın tekrarlı ve zaman alıcı olmasıdır — tam da yapay zekanın parladığı türden bir iş. Ama bir tuzak vardır: AI, çoğu zaman kodun var olan davranışını test eder, olması gereken davranışını değil. Bu farkı yönetmek, bu ünitenin özüdür.

Bu ünitede AI ile birim testi (bir fonksiyonu tek başına, izole şekilde sınayan test), kenar durum testleri ve test verisi üretmeyi; test kapsamındaki (coverage) boşlukları kapatmayı; ve AI testlerine körü körüne güvenmenin neden tehlikeli olduğunu ele alıyoruz.

Testin İki Yüzü: Davranışı Sabitlemek vs. Doğrulamak

Bir test iki farklı amaca hizmet edebilir. Birincisi doğrulama: kodun doğru olduğunu, spesifikasyona uyduğunu sınar. İkincisi regresyon koruması: kodun bugünkü davranışını dondurur, böylece yarın biri yanlışlıkla değiştirirse test kırılır ve haber verir.

AI, ikincisinde çok iyidir; koda bakıp "şu an ne yapıyorsa onu" test eden vakalar üretir. Ama kod baştan yanlışsa, AI bu yanlış davranışı "doğru" diye sabitleyebilir. Bu yüzden AI'nın ürettiği her testin beklenen değerini (assertion) siz gözden geçirmelisiniz: "Kod 42 döndürüyor ve test 42 bekliyor" ifadesi, 42'nin doğru cevap olduğu anlamına gelmez.

Dikkat: AI testi geçiyorsa kod "çalışıyor" demek değildir; yalnızca "AI'nın beklediği gibi davranıyor" demektir. Beklentinin doğru olup olmadığına spesifikasyona bakarak siz karar verirsiniz.

Adım Adım: AI ile Sağlam Test Yazmak

  1. Spesifikasyonu verin, sadece kodu değil. "Bu fonksiyon şunu yapmalı" bilgisini eklerseniz, AI doğru beklentiyi yazabilir; yalnızca kodu verirseniz mevcut davranışı test eder.
  2. Kenar durumları isteyin. Boş, null, sıfır, negatif, çok büyük, hatalı format, eşzamanlılık — mutlu yolun dışını açıkça talep edin.
  3. Test çerçevesini ve stilini belirtin. "pytest kullan", "Arrange-Act-Assert deseni", "her test tek şeyi sınasın" gibi.
  4. Beklentileri (assertion) denetleyin. Her assert'in doğru değeri kontrol ettiğini spesifikasyonla karşılaştırın.
  5. Kapsamdaki boşlukları kapattırın. Mevcut testleri verip "hangi dallar ve durumlar test edilmemiş?" diye sordurun; sonra üretilen ek testleri doğrulayın.

Üç Mini Vaka

Vaka 1 — Kapsam %52'den %85'e. Bir servis modülünün test kapsamı %52'ydi. Ekip, mevcut testleri AI'ya verip test edilmemiş dalları listeletti ve bunlar için testler ürettirdi. İnsan gözden geçirmesiyle birlikte kapsam %85'e çıktı; bu süreçte AI, daha önce hiç test edilmemiş bir hata dalında gerçek bir bug'ı (yanlış hata kodu dönen bir yol) ortaya çıkardı.

Vaka 2 — Yanlış beklentiyi sabitleme tuzağı. Bir para yuvarlama fonksiyonu aslında yanlıştı; 2,675'i 2,67 yerine 2,68 yuvarlaması gerekirken 2,67 döndürüyordu. AI, koda bakıp assert round_money(2.675) == 2.67 yazdı — yani hatayı "doğru" diye dondurdu. Geliştirici spesifikasyonu okuyunca beklentiyi düzeltti ve gerçek hatayı yakaladı. Kodu değil, kuralı test etmek fark yarattı.

Vaka 3 — Kenar durum patlaması. Bir tarih aralığı fonksiyonu için AI'dan yalnızca "kenar durumlar" istenince; başlangıç=bitiş, ters aralık, artık yıl 29 Şubat, farklı saat dilimleri ve boş aralık gibi 8 vaka üretti. Bunlardan ikisi (ters aralık ve artık yıl) gerçekten hataya yol açıyordu. Elle bu vakaları düşünmek genelde atlanır; AI burada bir "kenar durum beyin fırtınası" ortağı oldu.

Dört Kopyalanabilir Şablon

Spesifikasyon temelli test üretimi:

Rol: Test yazan bir geliştirici. Çerçeve: {{pytest/JUnit/Jest...}}.Fonksiyonun YAPMASI GEREKEN (spesifikasyon): {{kural}}Aşağıdaki fonksiyon için testler yaz. Beklentileri spesifikasyona göre yaz,kodun mevcut çıktısına göre DEĞİL. Mutlu yol + en az 4 kenar durum ekle.Her test tek şeyi sınasın, açıklayıcı isim kullan.{{fonksiyon}}

Kenar durum beyin fırtınası:

Bu fonksiyon için testte denenmesi gereken kenar/başarısızlık durumlarınılistele (boş, null, sınır değerler, hatalı format, eşzamanlılık, dış hata).Her durum için: girdi, beklenen davranış. Henüz kod YAZMA, sadece liste.{{fonksiyon}}

Kapsam boşluğu analizi:

Aşağıda fonksiyon ve mevcut testleri var. Hangi dallar, koşullar ve durumlartest edilmemiş? Eksikleri listele ve yalnızca eksikler için yeni testler yaz.Var olanları tekrarlama.Fonksiyon:{{fonksiyon}}Testler:{{mevcut_testler}}

Test verisi / sahte nesne (mock) üretimi:

{{fonksiyon/servis}} testleri için gerçekçi test verisi üret: geçerli örnekler,sınır örnekler ve geçersiz örnekler ayrı ayrı. Dış bağımlılık {{X}} için basitbir sahte (mock) davranışı öner. Gerçek gizli veri/PII kullanma; uydurma veri üret.

Zayıf prompt / Güçlü prompt

Zayıf: "Bu fonksiyona test yaz."
Güçlü: "pytest ile. Fonksiyon apply_discount(total, percent) — kural: indirim %0–%30 arası olmalı, sınırın dışı ValueError fırlatmalı, sonuç 2 ondalık yuvarlanmalı. Beklentileri bu KURALA göre yaz (koda göre değil). Mutlu yol + şu kenar durumlar: %0, %30, %31 (hata), negatif, total=0. [kod]"

Güçlü sürüm kuralı verir ve "beklentiyi koda göre değil kurala göre yaz" der; bu tek cümle, AI'nın yanlış davranışı sabitleme tuzağını kapatır.

Test tipi

AI katkısı

İnsan denetimi

Mutlu yol birim testi

Hızlı iskelet

Beklenti doğru mu?

Kenar durum vakaları

Geniş beyin fırtınası

İlgisizleri ele

Kapsam boşluğu doldurma

Atlanan dalları bulur

Anlamlılığı onayla

Test verisi/mock

Gerçekçi örnek üretir

PII yok, gerçekçilik kontrolü

Testler Kaliteyi Garanti Etmez, Yönetir

Yüksek test kapsamı güven verir ama yanıltıcı da olabilir: yüzde 100 kapsam, "her satır çalıştırıldı" demektir, "her satır doğru" demek değil. AI ile kapsamı artırmak kolaydır; asıl değer, anlamlı beklentiler yazmaktır. Bir testin değeri, kod bozulduğunda kırılıp sizi uyarma gücündedir. Bu yüzden AI'nın ürettiği testleri "kod değişince gerçekten kırılır mı?" sorusuyla sınayın; bir satırı kasten bozup testin kırıldığını görmek (mutation düşüncesi), testin işe yaradığının kanıtıdır.

İpucu: AI'nın yazdığı bir testin işe yarayıp yaramadığını anlamak için kodda küçük bir hata yaratın (ör. bir +'yı - yapın) ve testin kırılıp kırılmadığına bakın. Kırılmıyorsa o test sizi korumuyordur.

Sık yapılan hatalar

  • Kuralı vermeden test istemek. Model mevcut davranışı dondurur; hatayı "doğru" diye sabitler.
  • Beklentileri okumadan kabul etmek. assert'lerin doğru değeri kontrol ettiğini denetlemezseniz test aldatıcıdır.
  • Yalnızca mutlu yolu test etmek. Gerçek hatalar kenarlarda yaşar; kenar durumları açıkça isteyin.
  • Kapsamı amaç sanmak. Yüksek yüzde, doğru davranış garantisi değildir.
  • Gerçek/gizli veriyi test verisi yapmak. Müşteri verisi veya sır, testlere ve depoya girmemeli; sentetik veri üretin.

Özetle

AI, test yazmanın tekrarlı yükünü büyük ölçüde alır: hızlı iskeletler, geniş kenar durum listeleri ve kapsam boşluğu analizleri üretir. Ama en kritik nokta beklentilerdir: AI kodun mevcut davranışını test etmeye eğilimlidir, oysa test spesifikasyona göre yazılmalıdır. Kuralı verin, beklentileri denetleyin, kenar durumları zorunlu kılın ve testlerin gerçekten koruyup korumadığını bir hata enjekte ederek sınayın. Test kapsamı bir araçtır, hedef değil.

Uygulama görevi

Bir fonksiyon seçin ve önce sadece kodunu vererek AI'ya test yazdırın; beklentileri not edin. Sonra aynı fonksiyon için spesifikasyonunu (olması gereken davranışı) da vererek tekrar test yazdırın. İki test setinin beklentilerini karşılaştırın: farklı olan var mı, hangisi gerçek bir hatayı ortaya çıkarıyor? Son olarak üretilen testlerden birinin işe yaradığını, koda kasıtlı bir hata ekleyip testin kırıldığını görerek doğrulayın.

Kontrol listesi

  • [ ] Testin davranışı sabitlemek mi doğrulamak mı olduğunu ayırt ediyorum.
  • [ ] Test isterken kodu değil, olması gereken kuralı (spesifikasyon) veriyorum.
  • [ ] Üretilen her beklentiyi (assertion) spesifikasyonla karşılaştırıyorum.
  • [ ] Kenar ve başarısızlık durumlarını açıkça talep ediyorum.
  • [ ] Kapsam yüzdesini hedef değil, araç olarak görüyorum.
  • [ ] Bir testin gerçekten koruduğunu hata enjekte ederek sınıyorum.