Kazanimlar:
- Dağınık gözlemleri yapay zeka desteğiyle net başlık, deterministik tekrar üretim adımları, beklenen/gerçek sonuç ve kanıt içeren rapora dönüştürebilme
- Yapay zekaya 'yalnızca verdiğim bilgiyi kullan, uydurma' kuralını dayatıp tekrar üretilebilirliği kendi denetimiyle garanti edebilme
- Şiddet (teknik etki) ile öncelik (iş aciliyeti) kavramlarını ayırt edip nihai etiketi iş bağlamıyla verebilme
Bir test uzmanının bulduğu hata, ancak düzeltilirse değerlidir; düzeltilmesi ise büyük ölçüde hata raporunun (bug report — bir kusuru geliştiricinin anlayıp yeniden üretebileceği ve düzeltebileceği biçimde belgeleyen kayıt) kalitesine bağlıdır. Kötü yazılmış bir hata raporu ("giriş çalışmıyor") geliştiriciyi saatlerce oyalar, ileri geri yazışmalara yol açar ve çoğu zaman "üretemedim" (cannot reproduce) diye kapanır. İyi bir rapor ise net adımlar, beklenen ve gerçek sonuç, ortam bilgisi ve kanıt içerir. Yapay zeka (YZ), dağınık gözlemlerinizi profesyonel, yapılandırılmış bir rapora çevirmekte çok iyidir. Ama merkez uyarı burada da geçerli: YZ, sizin görmediğiniz adımları uyduramaz; eksik bilgiyi "makul görünen" ama yanlış tahminlerle doldurabilir. Sizin işiniz, raporun her satırının gerçekte gözlemlediğiniz şeye dayandığından emin olmaktır.
İyi hata raporunun anatomisi
Etkili bir rapor şu bileşenleri içerir:
- Başlık: Kısa, spesifik, aranabilir. "Hata var" değil; "Sepette 10'dan fazla ürünle 'Öde' butonu tıklanamıyor (Chrome)".
- Tekrar üretim adımları (steps to reproduce): Numaralı, sıfırdan izlenebilir, deterministik. Geliştirici bu adımları izleyince hatayı görebilmeli.
- Beklenen sonuç: Kabul kriterine göre ne olmalıydı.
- Gerçek sonuç: Ne oldu (hata mesajı, ekran, davranış).
- Ortam: Tarayıcı/cihaz, sürüm, ortam (test/canlı), kullanıcı rolü, veri.
- Kanıt: Ekran görüntüsü, video, log, hata izi (stack trace).
- Şiddet (severity) ve öncelik (priority): Aşağıda ayrıntılı.
İpucu: Bir raporu göndermeden önce "başka birine bu adımları versem, benim yardımım olmadan hatayı görebilir mi?" diye sorun. Cevap "hayır" ise rapor eksiktir. YZ raporu güzelleştirebilir ama tekrar üretilebilirliği ancak siz garanti edebilirsiniz.
Şiddet ve öncelik: karıştırılan iki kavram
Şiddet (severity) hatanın teknik etkisidir: sistem çöküyor mu, veri kayboluyor mu, yoksa yazım hatası mı? Öncelik (priority) ise ne kadar acil düzeltilmesi gerektiğidir; iş etkisiyle ilgilidir. İkisi her zaman aynı yönde gitmez: ana sayfadaki şirket adının yanlış yazılması düşük şiddetli ama yüksek önceliklidir (itibar). Nadir bir kenar durumdaki çökme yüksek şiddetli ama düşük öncelikli olabilir. YZ, gözlemi verdiğinizde bu ayrımı yapmanıza yardım eder; ama nihai etiketi iş bağlamını bilen siz verirsiniz.
Şiddet
Örnek
Öncelik
Örnek
Kritik (Blocker)
Ödeme tamamlanamıyor
Acil (P1)
Canlıda gelir kaybı
Yüksek (Major)
Rapor yanlış toplam veriyor
Yüksek (P2)
Yakın sürümde şart
Orta (Minor)
Nadir kenar durumda hata
Orta (P3)
Planlı sprint'te
Düşük (Trivial)
Buton hizası kayık
Düşük (P4)
Fırsat olunca
Zayıf prompt / Güçlü prompt
Zayıf: "Şu hatayı rapor et: ödeme çalışmıyor."
Güçlü: "Aşağıdaki gözlemlerimi standart hata raporu formatına çevir: başlık, tekrar üretim adımları (numaralı), beklenen sonuç, gerçek sonuç, ortam, şiddet ve öncelik önerisi (gerekçeli). Yalnızca verdiğim bilgiyi kullan; eksik alan varsa uydurma, 'BİLGİ EKSİK: ...' diye işaretle. Gözlemler: Chrome 120, test ortamı, sepette 12 ürün, 'Öde'ye basınca hiçbir şey olmuyor, konsolda 'undefined is not a function' hatası, 11 üründe sorun yok."
Güçlü prompt; formatı, "uydurma" kuralını ve eksik bilgi işaretlemesini dayatır. Böylece rapor hem düzgün hem dürüst olur.
Yinelenen (duplicate) hata tespiti
Büyük ekiplerde aynı hata defalarca raporlanır. YZ, yeni raporunuzu mevcut açık hatalarla karşılaştırıp olası yinelenenleri işaretleyebilir — bu, hata takip sisteminizi (Jira, Azure DevOps, GitHub Issues) temiz tutar. Ancak dikkat: yüzeyde benzer görünen iki hata farklı kök nedenlere sahip olabilir; YZ'nin "yinelenen" önerisini kapatmadan önce her iki raporun tekrar üretim adımlarını ve ortamını karşılaştırın. Yanlışlıkla kapatılan bir "yinelenen", aslında ayrı bir hatayı gözden kaçırmak demektir.
Hata izinden kök nedene: YZ'nin log okuma gücü
Bir hata raporunun en teknik parçası çoğu zaman hata izidir (stack trace — bir hatanın hangi kod satırından, hangi çağrı zinciriyle tetiklendiğini gösteren döküm). Uzun ve karmaşık loglar geliştiriciyi bile yorabilir. YZ, yüzlerce satırlık bir logu okuyup en kritik satırları, olası kök neden hipotezini ve hatanın tetiklendiği kod noktasını saniyeler içinde özetler. Bu, raporu hem kısaltır hem de geliştiriciye doğrudan bir başlangıç noktası verir.
Yine de iki sınırı unutmayın. Birincisi, YZ'nin verdiği kök neden bir hipotezdir, kanıt değildir; geliştirici bunu doğrulamadan düzeltmeye girişmemelidir. İkincisi, loglar sıklıkla kişisel veri (e-posta, kullanıcı kimliği, oturum jetonu) içerir; logu araca vermeden önce bu alanları maskeleyin. İyi bir pratik, YZ'ye önce "bu logda maskelenmesi gereken alanları listele" dedirtmek, sonra temizlenmiş logu analiz ettirmektir.
İpucu: Rapora tüm logu yapıştırmak yerine, YZ'nin özetlediği en kritik 3-5 satırı ve tam logun bir bağlantısını ekleyin. Böylece rapor okunur kalır, ayrıntıya ihtiyaç duyan geliştirici tam loga ulaşabilir.
Dört kopyalanabilir şablon
1) Gözlemden rapora:
Rolün: kıdemli QA. Aşağıdaki ham gözlemlerimi standart hataraporuna çevir: Başlık / Tekrar üretim adımları (numaralı) /Beklenen / Gerçek / Ortam / Kanıt notu / Şiddet + Öncelik (gerekçeli).KURAL: yalnızca verdiğim bilgiyi kullan; eksik alanı uydurma,"BİLGİ EKSİK: ..." diye işaretle.Gözlemler: [ham notlar]
2) Tekrar üretilebilirlik denetimi:
Bu hata raporunu, hatayı hiç görmemiş bir geliştirici gözüyle oku.Adımları izleyerek hatayı üretemeyeceği yerleri işaretle:belirsiz adım, eksik önkoşul, eksik test verisi, atlanmış durum.Her boşluk için hangi bilgiyi eklemem gerektiğini söyle.Rapor: [raporu yapıştır]
3) Şiddet/öncelik danışmanı:
Şu hatayı tarif ediyorum: [hata + iş bağlamı].Şiddet (teknik etki) ve öncelik (iş aciliyeti) için ayrı ayrıöneri ve gerekçe ver. İkisinin neden farklı olabileceğini açıkla.Nihai kararı ben vereceğim.
4) Log/hata izi özeti:
Aşağıdaki hata izini/logu incele. Bana (1) kök neden hipotezi,(2) hatanın oluştuğu olası kod noktası, (3) rapora ekleneceken kritik 3 satır özetini ver. Kişisel veri varsa maskele.Log: [logu yapıştır]
Üç mini vaka
Vaka 1 — "Üretemedim"den kurtuluş. Bir ekipte hataların %30'u "cannot reproduce" diye kapanıyordu. "Tekrar üretilebilirlik denetimi" şablonu rapor sürecine eklendi; her rapor gönderilmeden önce YZ eksik adım ve önkoşulları işaretledi. Üç ay sonra "üretemedim" oranı %30'dan %8'e düştü. Fark, adımların baştan tam olmasıydı.
Vaka 2 — Uydurma adım tehlikesi. Bir testçi, YZ'ye eksik gözlemle rapor yazdırdı; YZ "kullanıcı ayarlar sayfasından bildirimleri açar" gibi hiç yaşanmamış bir adım ekledi. Geliştirici o adımı izleyince hatayı bulamadı, saat kaybetti. Ekip "yalnızca verdiğim bilgiyi kullan, uydurma" kuralını zorunlu kıldı; uydurma adımlar ortadan kalktı.
Vaka 3 — Şiddet/öncelik ayrımı. Ana sayfada şirket sloganında yazım hatası vardı. Testçi bunu "düşük" diye geçecekti; YZ danışmanı, teknik şiddetin düşük ama iş önceliğinin yüksek olduğunu (her ziyaretçinin gördüğü itibar unsuru) hatırlattı. Hata "yüksek öncelik" etiketiyle aynı gün düzeltildi.
Sık yapılan hatalar
- Belirsiz başlık. "Çalışmıyor" gibi aranamayan, ayırt etmeyen başlıklar.
- Eksik/atlamalı adımlar. Kendi bağlamınızda bariz olanı yazmamak; geliştiricinin üretememesi.
- YZ'nin uydurmasına izin vermek. Eksik bilgiyi "makul tahminle" doldurtmak; yanlış adımlar.
- Beklenen sonucu yazmamak. "Yanlış" demek ama neyin doğru olduğunu belirtmemek.
- Şiddet ve önceliği karıştırmak. İkisini tek etiket sanmak; iş etkisini yanlış değerlendirmek.
- Kanıtta hassas veri. Ekran görüntüsü/logda gerçek kişisel veriyi maskelemeden paylaşmak.
Özetle
Hata raporunun değeri, geliştiricinin hatayı sizin yardımınız olmadan yeniden üretip düzeltebilmesindedir. YZ dağınık gözlemleri profesyonel, yapılandırılmış rapora çevirmekte çok iyidir; başlık, adımlar, beklenen/gerçek sonuç, ortam ve kanıtı düzenler, şiddet-öncelik ayrımında danışmanlık yapar. Ama YZ eksik bilgiyi uydurabilir; "yalnızca verdiğim bilgiyi kullan, eksiği işaretle" kuralını dayatın ve tekrar üretilebilirliği kendiniz garanti edin. Kanıtlardaki kişisel veriyi maskeleyin.
Uygulama görevi
Son bulduğunuz bir hatayı alın ve ham gözlemlerinizi "gözlemden rapora" şablonuyla rapora çevirin ("uydurma" kuralıyla). Ardından "tekrar üretilebilirlik denetimi"ni uygulayıp işaretlenen boşlukları doldurun. Raporu bir meslektaşınıza verin ve sizin yardımınız olmadan hatayı üretip üretemediğini ölçün. Son olarak "şiddet/öncelik danışmanı" ile etiketleri belirleyip kendi kararınızla sonlandırın. Süreçte YZ'nin uydurmaya çalıştığı herhangi bir bilgiyi not edin.
Kontrol listesi
- [ ] Başlığım spesifik ve aranabilir.
- [ ] Tekrar üretim adımları sıfırdan, deterministik ve tam.
- [ ] Beklenen ve gerçek sonucu ayrı ayrı yazdım.
- [ ] Ortam ve kanıt bilgisi eksiksiz; kişisel veriyi maskeledim.
- [ ] YZ'ye "uydurma, eksiği işaretle" kuralını dayattım ve boşlukları kendim doldurdum.
- [ ] Şiddet ve önceliği ayrı değerlendirip nihai kararı ben verdim.