Cevap.

Konu Tarihi:

Hata takip sistemlerinin ortaya çıkmasından bu yana, test mühendisleri şu soruyla karşı karşıya kaldı: Hataları, geliştiricinin ekstra sorular sormadan tekrar edebilmesi ve düzeltebilmesi için nasıl iletebiliriz? İşte tam da bu nedenle, adımların, ortamın, ortaya çıkma koşullarının ve gerçek sonucun net bir şekilde belgelenmesi kültürü ortaya çıktı.

Sorun:

Kötü hazırlanmış bir hata raporu, ekip içinde uzun süren tartışmalara ve yanlış anlamalara neden olabilir. Çoğu zaman hata kaybolur, tekrarlanamaz ve "tekrar edilemediği" gerekçesiyle kapatılır, bu da hatanın sistemde yaşamaya devam etmesine sebep olur.

Çözüm:

Yapılandırmaya kesinlikle uymak: yeniden üretim adımları, beklenen ve gerçek sonuç, ortam, önem derecesi, gerektiğinde — ekran görüntüleri veya loglar eklemek.
Hataları "temiz ellerle" kontrol etmek: yeni bir kullanıcıyla, boş bir önbellekle, temiz bir tarayıcıyla.
Hata raporları için şablonları ve kontrol listelerini kullanmak.

Anahtar özellikler:

Adımların netliği gerekliliği (tarihsel olarak — hatanın herkes tarafından yeniden üretilebilir olması için).
Minimum bilgi setinin belirtilmesi: ortam (yazılım sürümü, tarayıcı, işletim sistemi).
Hataların gösterimi (ekran görüntüleri, loglar, videolar).

Tuzağa Düşüren Sorular.

Eğer ekipte herkes "zaten anladı" ise, hatayı sadece sözlü olarak belgelemek mümkün mü?

Hayır. Yerleşik ekiplerde bile, hatayı resmî olarak belgelemek her zaman önemlidir: değişim geçmişi, ekip kadrosunun döngüsü ve hatanın hatırlanması sonsuz değildir.

Her hatayı "sıfırdan" (giriş/çıkış vb.) yazmak gerekli mi?

Eğer hataya giden adımlar basitse (standart giriş) — atlanabilir, ancak oturum, profil ayarları veya ayarlar özgünse — tam yeniden üretim kritik öneme sahiptir.

Tüm hataların ekran görüntüleri/videolarla desteklenmesi gerekir mi?

Her zaman değil. Eğer hata açıklamadan açıkça görülüyorsa (yazım hatası), ekran görüntüsü yararlı ama zorunlu değil. Ancak hata görsel görüntüleme/düzenleme ile ilgiliyse, mutlaka görsel bir kanıt eklenmelidir.

Tipik Hatalar ve Anti-Desenler

Hataların belirsiz veya eksik tanımı ("bir şey çalışmıyor")
Ortam hakkında bilgi eksikliği
Yeniden üretim adımlarının eksikliği

Hayattan Bir Örnek

Olumsuz Durum

Test mühendisi "Buton çalışmıyor" hatasını adım ve ortam belirtmeden açar. Geliştirici hatayı tekrarlayamaz.

Avantajları:

Talepleri oluşturmak için zaman tasarrufu.

Dezavantajları:

Hata kapatılmadan kalır veya test mühendisine geri döner, iletişim kötüleşir.

Olumlu Durum

Test mühendisi hatayı şekillendirir: adımları, uygulama sürümünü, tarayıcıyı belirtir, ekran görüntüsü ve sistem logu ekler.