El Testi (IT)Test Uzmanı (Manual QA)

El yapımı testlerde hata raporlarını değerli hale getirmek için nasıl düzgün bir şekilde oluşturmalıyız?

Hintsage yapay zeka asistanı ile mülakatları geçin

Cevap.

Soru Tarihi:

Hata raporu — test uzmanının temel belge türüdür. On yıllar boyunca hata raporlarının kalitesi, QA ve DEV departmanları arasındaki iletişim hızını belirlemiş, hata düzeltme süresini kısaltmış veya uzatmıştır.

Problem:

Zayıf hazırlanmış hata raporları (belirgin adımların olmaması, belirsiz açıklama, beklenen davranışın olmaması) görevlerin yanlış yorumlanmasına ve hataların yanlış düzeltilmesine yol açar, ek açıklamalar için zaman kaybına neden olur. Bu, ekipler arasında çatışmalara neden olan temel bir sebeptir.

Çözüm:

  • Yapıya sadık kalmak: başlık, öncelik/ciddiyet, çevre, yeniden üretim adımları, gerçek sonuç, beklenen sonuç, ekran görüntüleri/video/loglar.
  • Gereksiz duygulardan ve öznel değerlendirmelerden kaçınarak mümkün olduğunca yapılandırılmış ve net bir dil kullanmak.
  • Raporu göndermeden önce kontrol etmek — diğer çalışanların kaydedilen adımlarla hatayı yeniden üretme girişimi.
  • Şirketin benimsediği şablona göre alanları doldurmak (Jira, DevOps, YouTrack vb.).

Anahtar Özellikler:

  • Net yapı ve yeniden üretilebilirlik.
  • Hataların çevre ve uygulama sürümü ile güncel ilişkisi.
  • Hataları öznel değerlendirmeler yerine gerçeklerle, belgelerle desteklemek.

Hileli Sorular.

Benzer hataları (örneğin, farklı arayüz bileşenleri için) tek bir hata raporunda birleştirmek mümkün mü?

Hayır. Her hata — ayrı bir hatadır, çünkü birinin düzeltilmesi diğerlerini çözmeyebilir. İstisna — aynı doğaya sahip kitlesel hatalardır (örneğin, küresel stil kaybı).

"Çalışmıyor"/"Açılmıyor" yeterince iyi bir başlık mıdır?

Hayır. Başlık, somut olmalıdır (örneğin, "[Profil] Kayıt butonu geçerli veriler girildikten sonra aktif değil").

Hata açıkça ortadaysa, adımları sadece minimum şekilde belirtmek gerekir mi?

Hayır. Açık olan hatalar bile net bir şekilde tanımlanmalıdır — belirsizliklerden kaçınmak ve ürün tarihi için.

Tipik Hatalar ve Anti-Örnekler

  • Beklenen sonucun olmaması.
  • Detay içermeyen genel ifadeler.
  • Kişisel değerlendirmelerin veya duyguların eklenmesi ("korkunç hata", "acilen düzeltilmeli").

Gerçek Hayattan Örnek

Olumsuz Durum

Test uzmanı, metin olarak şu hata raporunu yazdı:

Buton çalışmıyor.

ve adım, çevre ve beklenen sonuç belirtmeden. Geliştirici hatayı yeniden üretemedi, rapor "Yeniden Üretilemez" olarak kapatıldı.

Artılar:

  • Hızla hazırlanmış.

Eksiler:

  • Hata kayboldu, takımda yanlış anlamalar oluştu.

Olumlu Durum

Test uzmanı detaylı bir şekilde yazdı:

  • Hatanın hangi tarayıcıda ve sürümde meydana geldiği
  • Detaylı adımlar listesi
  • Beklenen ve gerçek davranış
  • Ekran görüntüleri ve loglar ekledi
  • Kullanıcı hikâyesine bağlantıyı açıkça belirtti

Artılar:

  • Hatanın hızlı ve doğru düzeltilmesi.
  • QA ve DEV arasında saygı.

Eksiler:

  • Belgeleme için biraz daha fazla zaman harcanır.