🐛 Bug Analizi & Rapor

Bug Analizi & Rapor: Ham, temizlenmemiş bir log'u Claude'a yapıştırmak, tek bir belgeyi teslim etmesi için bir kuryeye tüm cüzdanını vermeye benzer — mekanizma birebirdir: kurye

Ham, temizlenmemiş bir log'u Claude'a yapıştırmak, tek bir belgeyi teslim etmesi için bir kuryeye tüm cüzdanını vermeye benzer — mekanizma birebirdir: kurye sadece belgeye (hata satırına) ihtiyaç duyuyordu, aynı zarfta (log dosyasında) tesadüfen bulunan kimlik kartına ve kredi kartlarına (session token'ları, e-postalar, IP'ler) değil. Üzerinde durulmaya değer soru şu: Claude sana yardım etmek için sadece HATA'ya ihtiyaç duyuyorsa, neden bu kadar çok tester ham log'un tamamını, müşteri e-postaları ve auth token'ları dahil, yapıştırıyor? Çünkü temizlemek fazladan bir sürtünme adımı gibi hissettiriyor — ama o sürtünme GÜVENLİK MEKANİZMASININ ta kendisidir: bir sır terminalinden herhangi bir dış servisin isteğine gittiği an, senin kontrolündeki sızmış bir API key'i döndürebildiğin gibi bu sızıntıyı geri alamazsın. Java karşılaştırması: bu, catch(Exception e) { log.error(e.getMessage()) } içinde getMessage()'ın tesadüfen şifre içeren ham bir JDBC bağlantı dizesi taşıması sınıfından bir hatadır — temizlemeyen loglama framework'leri bilinen gerçek olay kaynaklarıdır, bir AI sohbetine yapıştırmak aynı akışın bir sıçrama (bir üçüncü taraf) çıkarılmış halidir. QA tarafındaki bedel varsayımsal değildir: paylaşılan bir Claude konuşmasında sızan bir session token veya müşteri e-postası (bir ekip kanalına atılan ekran görüntüsü, kurumsal bir log-saklama politikası) gerçek bir gizlilik olayıdır — bir şeyin hassas göründüğünü FARK ETTİKTEN sonra değil, HER ZAMAN yapıştırmadan ÖNCE temizle.

Stack Trace'den Sıralı Hipotezlere

Temizlenmiş stack trace'i yapıştır ve Claude'dan olası kök nedenleri, her biri için gerekçesiyle birlikte olasılığa göre sıralamasını iste — tek bir "asıl" nedeni ilan etmesini değil. Cevabı, bir meslektaşının eğitimli tahmini gibi test edilecek bir hipotezler kümesi olarak ele al, bir hüküm olarak değil.

Akıl yürütme: flaky bir testin sadece en son başarısızlığı yerine son 3-5 koşumunun log'unu neden birlikte yapıştırasın? Tek bir başarısızlık log'u normal, tek seferlik bir hipotez gibi görünür: "element bulunamadı." Ama farklı aralıklı noktalardaki 3-5 log bir ÖRÜNTÜYÜ ortaya çıkarabilir — paralel çalıştırıldığında her zaman başarısız olması, ya da sadece belirli bir önceki testten sonra olması — ki bunu tek bir log gösteremez. Düzeltme örüntüde yaşar, herhangi bir tekil stack trace'te değil.

Adım Adım: Log'dan Bug Raporuna

Hiçbir şey yapıştırmadan önce log'daki e-posta, token, IP ve müşteri adları temizlenir.

Flaky test için birden fazla koşum yapıştır

Tek bir başarısızlık log'u rastgele görünür; aynı flaky testin 3-5 koşumu bir ÖRÜNTÜ ortaya çıkarır.

Olasılık sıralı hipotez iste

Tek bir "kesin neden" yerine, olasılığa göre sıralanmış kök neden hipotezleri gerekçeleriyle istenir.

Önerilen bir severity/priority VE gerekçesiyle birlikte yapılandırılmış bir bug raporu istenir.

Göndermeden önce doğrula

En olası hipotez sen tarafından tekrar üretilir; nihai severity gerçek iş etkisine göre SEN tarafından belirlenir.

Ham bir hatadan güvenli bir bug raporuna giden akışı doğru sıraya diz.