Bir hatayı düzeltip haftalar sonra aynı hatanın geri geldiğini görmek, yazılımın en yorucu anlarından biridir. Suçlanacak biri değil, öğrütülecek bir süreç vardır. Regresyon avı, hatanın neden geri döndüğünü bulup aynı yoldan tekrar gelmesini engelleyen disiplindir. Kısa vadeli hedefi hatayı kapatmak değil, uzun vadeli hedefi savunmayı kurmaktır. İyi yapılan bir regresyon avı, hatayı bir kez daha görmekle kalmaz; ekibin test mimarisini, inceleme alışkanlıklarını ve kayıt disiplinini de olgunlaştırır. Bu yazı, hatanın geri dönüş yolunu nasıl kesintiye uğratacağımızı anlatıyor.

Regresyon nasıl geri gelir?

İlk yol, testin hiç yazılmamış olmasıdır. Hata düzeltildi ama davranışı kilitleyen bir test yok; altı ay sonra aynı satırı başka bir geliştirici, aynı düşünceyle yeniden yazar. İkinci yol, testin silinmesi veya "güncellenmesidir": davranış değiştiğinde test de değiştirilir, asıl savunulması gereken sözleşme kaydedilmeden atılır.

// Hata düzeltildiğinde yazılan test, davranışı kilitler
it("reddedilen yorum yayına çıkmaz", () => {
  const yorum = yorumYap({ durum: "reddedildi" });
  expect(yayinla(yorum)).toBe(false);
});

Üçüncüsü sessizdir: test vardır, ama farklı bir katmandadır. Birim testi korur, refactor sırasında o satır silinir; uçtan uca test aynı davranışı doğrulamıyorsa hata sessizce geri döner. Katmanlar arasındaki bu kör nokta, ekibin "ama testimiz vardı" dediği ama kanıt sunamadığı yerdir. Savunmayı tek bir test dosyasına havale etmek yerine, kritik davranışın en az iki katmanda kaydı olmalıdır: biri hızlı, biri gerçek.

Avın ilk adımı: geri dönüşü anlamak

Hata geri döndüğünde ilk soru "kim bozdu" değil, "hangi savunma çalışmadı" olmalıdır. Üç seçenek vardır: test yoktu, test vardı ama silindi, test vardı ama yeterli değildi. Cevap, düzeltmeyle birlikte yazıya dökülür; üçüncü kez geri dönen hata, süreç hatasıdır ve kök neden kaydı tutulmalıdır.

# Hata geri döndüğünde: hangi commit'te doğdu?
git log -S "reddedildi" --oneline -- lib/yayin.ts

Sprintlere yaymak

Regresyon avı, sprint ritmine bağlanınca değer üretir. Her sprint sonunda geri dönen hataların listesi çıkarılır; her hata için hangi savunmanın eksik olduğu yazılır. Eksik test varsa ilk iş o sprintte tamamlanır. Kayıt defterinde tutulan bu liste, altı ay sonra ekibin gerçek test kültürünü en iyi anlatan belgedir; kapsamı değil, savunmayı anlatır. Listenin özeti tek sorudur: hangi hata kaç kez döndü, hangi savunma onu sonunda durdurdu? Cevap, ekibin bir sonraki mimari kararının gündemidir.

Bir de işin insani tarafı vardır: hata geri döndüğünde suçlu aramak, ekibi kayıt tutmaktan uzaklaştırır. Kayıt tutan ekip ise aynı hata üçüncü kez geldiğinde cevabı ekranda görür: hangi test, hangi katman, hangi gözden kaçan kural. Soru suçlama değil, mimaridir. Suç arayan ekip sonraki hatayı gizler; süreç sorgulayan ekip ise hatayı veriye çevirir.

Son söz: hata geri döndüğünde üzülmeyin, okuyun. Hangi katman sustu, hangi test eksildi, hangi inceleme atlandı? Cevaplar yine yazılımda, ama ders süreçte.