Kısaca. İyi bir hata raporu geliştiricinin hatayı ilk denemede kendi telefonunda görmesini sağlar. Bunun için beş şey gerekir. Kısa ve net bir başlık, hatanın çıktığı ortam, adım adım ne yapıldığı, ne beklendiği ile ne olduğu ve kanıt. Mobilde ortam bilgisi uygulamalardan daha önemlidir, çünkü aynı hata sadece belirli bir dilde, pil seviyesinde ya da şebekede çıkabilir. Aşağıda her alanı anlattık ve kopyalayabileceğiniz bir şablon ekledik.
Hata raporu neden önemli?
Bir hata raporunun tek işi var. Okuyan kişinin hatayı görmesini sağlamak. Rapor bunu yapamazsa aynı konuşma tekrarlanır. “Bende çalışıyor.” “Hangi telefondaydın?” “Hatırlamıyorum.” Hata kapatılır ve bir sonraki sürümde yine çıkar.
Mobilde bu daha sık olur. Aynı uygulama farklı telefonlarda, dillerde ve şebekelerde farklı davranır. Raporda bu bilgiler yoksa geliştirici hatayı bulamaz.
İyi bir hata raporunun alanları
| Alan | Ne yazılır | Örnek |
|---|---|---|
| Başlık | Nerede, ne oldu | Geçmişte iptal edilmiş yolculuğa dokununca uygulama kapanıyor |
| Ortam | Telefon, Android sürümü, uygulama sürümü, dil, şebeke, pil | Android 16, Türkçe, Wi-Fi |
| Adımlar | Hatayı yeniden üreten adımlar, sırayla | 1. Giriş yap 2. Yolculuklarım’ı aç 3. İptal edilmiş yolculuğa dokun |
| Beklenen | Ne olması gerekiyordu | Yolculuğun detay ekranı açılmalı |
| Olan | Gerçekte ne oldu | Uygulama “RideGo durdu” uyarısıyla kapandı |
| Sıklık | Her seferinde mi, bazen mi | Her denemede |
| Kanıt | Video, ekran görüntüsü, çökme kaydı | Videonun 2:16 saniyesi, çökme kaydı ekte |
| Önem | Kullanıcıyı ne kadar etkiliyor | Yüksek, uygulama kapanıyor |
Her alanı doğru doldurmak
Başlık
Başlık tek başına hatayı anlatmalı. “Uygulama çöküyor” yetersizdir, çünkü uygulama yüz farklı yerde çökebilir. “Yolculuklarım’da iptal edilmiş kayda dokununca uygulama kapanıyor” okuyanın hangi ekrana bakacağını söyler.
Ortam
Mobilde en çok unutulan alan budur. Telefon modeli ve Android sürümünün yanına şunları da yazın.
- Uygulamanın sürüm numarası
- Telefonun dili ve bölgesi
- Şebeke türü ve durumu
- Pil seviyesi, özellikle düşükse
- Ekranın yönü, yatay mı dikey mi
Bu bilgilerden biri hatanın asıl sebebi olabilir. Sadece Almanca dilde taşan bir düğme ya da sadece pil yüzde beşin altındayken donan bir ekran gibi.
Adımlar
Adımlar bir tarif gibi yazılmalı. Her satırda tek bir eylem. Başlangıç noktasını belirtin, “uygulamayı açtıktan sonra” gibi. Adımları yazdıktan sonra bir kez daha uygulayın ve hatanın gerçekten çıktığını kontrol edin.
Beklenen ve olan
Bu iki alan yan yana yazılmalı. Beklenen alanı olmadan okuyan kişi neyin hata olduğunu anlamayabilir. Bazen “hata” dediğimiz şey tasarlanmış bir davranıştır, beklenen alanı bu tartışmayı baştan çözer.
Kanıt
Bir video yüzlerce kelimeden fazlasını anlatır. Özellikle kesinti, zamanlama ve animasyon hatalarında video şarttır. Uygulama çöktüyse Android’in ürettiği çökme kaydını ekleyin. Geliştirici bu kayıtta hatanın kodun hangi satırından geldiğini görür.
Kopyalayabileceğiniz şablon
Başlık: [Ekran] üzerinde [eylem] yapınca [sonuç]
Ortam
- Telefon ve Android sürümü:
- Uygulama sürümü:
- Dil ve bölge:
- Şebeke:
- Pil:
Adımlar
1.
2.
3.
Beklenen:
Olan:
Sıklık: (ör. 3 denemede 3)
Kanıt: (video, ekran görüntüsü, çökme kaydı)
Önem: (düşük, orta, yüksek, kritik)Gerçek bir örnek
İçine bilerek hata koyduğumuz RideGo uygulamasında bir test şu hatayı buldu. Rapor şöyle özetlenebilir.
- Başlık. Geçmişte iptal edilmiş yolculuğa dokununca uygulama kapanıyor.
- Adımlar. Giriş yap, yan menüden Yolculuklarım’ı aç, Galata Tower adlı iptal edilmiş yolculuğa dokun.
- Beklenen. Yolculuğun detay ekranı açılmalı.
- Olan. Detay ekranı açılmadı, uygulama tamamen çöktü ve ekranda “RideGo durdu” başlıklı hata penceresi belirdi.
- Kanıt. Testin videosu ve çökme kaydı. Kayıtta hatanın yolculuk geçmişi ekranından geldiği görünüyor.
Bu raporu okuyan bir geliştirici hangi ekrana, hangi kayda ve kodun hangi satırına bakacağını ilk okumada biliyor.
Sık yapılan hatalar
- Birden fazla hatayı tek raporda toplamak. Her hata ayrı bir rapor olmalı, yoksa biri düzelince rapor kapatılamaz.
- Tahmin yazmak. “Sanırım sunucudan kaynaklanıyor” yerine sadece görüleni yazın.
- Ekran görüntüsünü tek kanıt yapmak. Görüntü sonucu gösterir, oraya nasıl gelindiğini göstermez.
- Sürüm numarasını atlamak. Hata eski bir sürümde düzeltilmiş olabilir.
Sık sorulan sorular
Hata raporu ile test raporu arasındaki fark ne?
Test raporu bir testin sonucunu anlatır, geçti mi kaldı mı. Hata raporu bulunan tek bir hatayı ve onu nasıl yeniden üreteceğinizi anlatır. Kalan bir test genelde bir hata raporuna dönüşür.
Önem ile öncelik aynı şey mi?
Hayır. Önem hatanın kullanıcıyı ne kadar etkilediğidir. Öncelik ise ne zaman düzeltileceğidir. Az kişiyi etkileyen ama ödeme ekranında çıkan bir hata yüksek öncelikli olabilir.
Hatayı yeniden üretemiyorsam rapor açmalı mıyım?
Evet, ama bunu açıkça yazın. Sıklık alanına “1 denemede 1, sonra tekrar etmedi” yazın ve elinizdeki videoyu ekleyin. Bazı hatalar sadece belirli bir durumda çıkar.
Rapor ne kadar uzun olmalı?
Hatayı yeniden üretmeye yetecek kadar. Genelde bir başlık, beş satır ortam, beş adım ve bir video yeterlidir.
TestSafe’te hata raporu
TestSafe’te bir test bittiğinde rapor bu alanların çoğunu kendiliğinden içerir. Hangi telefonda, hangi sürümde ve hangi ortamda çalıştığı, ajanın attığı adımlar, her beklentinin sonucu, testin videosu ve uygulama çöktüyse çökme kaydı. Jira bağlıysa kalan bir test için kayıt bu bilgilerle açılır.
Bir raporun içini Raporlar sayfasında görebilirsiniz.