🐞 Bug Raporlama Sanatı

Bug Raporlama Sanatı: İyi bir bug raporu, bir kaza tutanağına benzer. Tutanağı yazan kişi olay yerinde tek başınadır; onu okuyacak eksper ise oraya asla gitmeyecektir.

İyi bir bug raporu, bir kaza tutanağına benzer. Tutanağı yazan kişi olay yerinde tek başınadır; onu okuyacak eksper ise oraya asla gitmeyecektir. Bu yüzden tutanakta "araba çarptı" yazmaz — hangi kavşak, hangi şerit, hangi hava koşulu, hangi hız, hangi iz. Amaç, okuyanın olayı zihninde yeniden kurabilmesidir. Düşündürücü soru: developer iki metre ötende otururken ve konuyu on saniyede anlatabilecekken, on dakikanı bir rapor yazmaya harcamak neden mantıklı olsun? Çünkü raporu okuyacak kişi çoğu zaman o developer değildir: gece nöbetindeki başka bir mühendis, altı ay sonraki yeni ekip üyesi, ya da aynı hatayı ikinci kez gören sensin. Karşılaştır: bir test kırıldığında elinde "assertion failed" değil, beklenen ve gerçekleşen değeri yan yana veren bir çıktı olsun istersin. Bug raporu da tam olarak budur — insan diliyle yazılmış bir assertion mesajı. "Ödeme çalışmıyor", assertion mesajı olmayan bir fail'dir. QA açısından ölçülebilir bedeli şudur: eksik rapor "cannot reproduce" ile geri döner. Her geri dönüş iki kişinin gününü böler, bug'ın yaşını uzatır ve en kötüsü, gerçek bir hatanın "tekrar üretilemiyor" etiketiyle kapanmasına yol açar. Rapor yazma disiplini bir nezaket değil, hata bulma işinin son adımıdır.

🎬 Kötü Bir Bug Raporunun 5 Günü

Ayşe Yeniden Test Ediyor

Rapor Yeniden Yazılır

Gün 1, 09:00 — Ayşe bir bug buluyor ve raporu üç saniyede yazıyor: başlık "Ödeme çalışmıyor", açıklama yok. Panoda görünür hâle geldi diye kendini rahat hissediyor. Aslında iş daha yeni başlıyor.

Gün 2 — Mert raporu açar, kendi test verisiyle dener, hiçbir sorun bulamaz. Elinde ortam, adım veya kanıt olmadığı için tek yapabileceği "cannot reproduce" yazıp raporu geri göndermektir.

Gün 3 — Ayşe kaydı geri alır ama İKİ GÜN önce hangi kuponu, hangi ürünü kullandığını tam hatırlamıyor. Baştan test etmesi gerekiyor — kendi hatasını kendi zamanından çalarak ödüyor.

Gün 4 — Bu sefer rapor tam yazılır: ortam, ön koşul, deterministik adımlar, beklenen/gerçekleşen, kanıt. Mert raporu açar ve BEŞ DAKİKADA aynı hatayı üretir — üç gün önce imkânsız görünen şey, tam bir rapor ile beş dakikaya iner.

Final (kontrast) — Gün 5'te bug düzeltilir ve doğrulanır. Toplam maliyet: 5 gün, iki kişinin kaybettiği zaman, bir "cannot reproduce" damgası. Rapor Gün 1'de tam yazılsaydı bu süreç birkaç SAATE sığardı — arada değişen tek şey raporun tamlığıdır, hatanın kendisi değil.

1️⃣ D1. İyi Bir Bug Raporunun Anatomisi

Bir bug raporunun altı zorunlu parçası vardır ve her biri farklı bir soruya cevap verir: Başlık (hangi ekranda ne oldu?), Ortam (hangi tarayıcı/sürüm/işletim sistemi?), Ön koşul (hangi kullanıcı, hangi veri?), Adımlar (hangi sırayla tıklandı?), Beklenen/Gerçekleşen (ne olmalıydı, ne oldu?), Kanıt (bunu ne kanıtlıyor?). Altısından biri eksikse okuyan kişi o boşluğu KENDİ varsayımıyla doldurur — ve genelde yanlış varsayar.

Adım Adım: "Ödeme Çalışmıyor" Raporu Nasıl Kullanılabilir Hâle Gelir?

Başlangıç: hiçbir şey söylemeyen başlık

"Ödeme çalışmıyor" başlığı panoda otuz kartın arasında hiçbir karar aldırmaz. Başlık, okuyanın kartı açmadan önceliklendirebilmesini sağlamalıdır.