Örneklerle Hata Raporu Nasıl Yazılır
Lucas Bennett
Hata Raporu Nedir? Neden iyi bir hata raporuna ihtiyacınız var?
Hata Raporu, STLC'de test ekibine çeşitli avantajlar sunan önemli bir belgedir. Yazılım testi sırasında bulunan tüm kusurları, çoklu hataları, hataları ve diğer tutarsızlıkları takip eder ve rapor eder.
Bu test sonrası dokümantasyonun amacı, ilgili profesyonellerden oluşan ekibe, test süreci sırasında karşılaşılan hataların düzeyi hakkında bilgi sağlamaktır.
kg yazılım geliştirme mühendisi Bu tür bir rapor kullanılarak yazılımdaki tüm kusurlar ve sorunlar hakkında bilgi sahibi olunabilir. Ayrıca bir hatanın ne olduğunu anlamanıza da olanak tanır, böylece onu düzeltmek için en iyi yöntemi kullanabilirsiniz. Ayrıca hataları ve sorunları yakalamanıza yardımcı olarak zamandan ve paradan tasarruf etmenize de yardımcı olur.
Neden iyi hata açıklamalarına önem vermelisiniz?
İyi ve detaylı bir yazılım hata raporu yazmak için dikkat etmeniz gereken nokta şudur:
- Gelecek sürümlerde aynı hatanın önlenmesine yardımcı olacak bir rehber görevi görür.
- İletişime (e-posta, arama) zaman ayırın.
- Less geliştiriciler için çalışın (tam olarak istediğinizi yapacaklar).
- Projede daha az darboğazla karşılaşacaksınız; hatalar daha hızlı ve daha verimli bir şekilde düzeltilecektir.
Hata Raporu Nasıl Yazılır (Hata Raporu Şablonu)
Hata izleme sisteminize bağlı olduğundan kesin bir hata raporu şablonu yoktur. Şablonunuz farklı olabilir.
Ancak bir hata raporu yazmak istediğinizde aşağıdaki ortak alanlara her zaman ihtiyaç duyarsınız:
- Hata kimliği/Başlığı.
- Şiddet ve Öncelik.
- Açıklama
- çevre
- Çoğalma adımları.
- Beklenen Sonuç.
- Gerçek sonuç.
- Ekler (ekran görüntüleri, videolar, metin)
Tüm bu hata giderme bileşenlerine tek tek bakalım:
1) Başlık/Hata Kimliği:
Her hataya benzersiz bir kimlik numarası verilmelidir. Hata raporlama araçları, yeni ortaya çıkan hatalar için benzersiz numaralar olmalıdır, böylece hatayı kolayca tanımlayabiliriz.
Örnekler:
❌ Kötü: “Ürünü tekrar gördüğümde göremiyorum, görünmüyor.”
- belirsiz
- Agresif
- Çok geveze
Çözümün hayata geçirilmesini istiyor.
✅ İyi: “SEPETE – Görünmeyen yeni ürünler sepete eklendi”.
- Bu tür bir Başlık, sorunu anında tespit eder (CART)
- Gerçek teknik soruna odaklanır.
2) Hata Önem Derecesi:
Hatanın ciddiyeti, hata raporunda çok önemli bir faktördür. Kusurun uygulamanın performansı üzerindeki etkisini açıklar.
- Engelleyiciler: Bu hata uygulamanın başarısız olmasına neden olur.
- Binbaşı: Kritik bir hata, iş mantığında büyük bir değişiklik olduğunu gösterir.
- Minör: Uygulamanın işlevselliğini etkilemeyen ancak beklenen sonuçları etkileyen bir sorun.
- Önemsiz: Uygulamanın işlevselliğini veya çalışmasını etkilemez. Bir yazım hatası olabilir.
3) Hata Önceliği:
Hata önceliğini belirlemek için genel derecelendirme şu şekildedir:
- Yüksek: Akışı etkileyen veya uygulama kullanımını engelleyen her şeyi kapsar.
- Orta: Kullanıcı deneyimini olumsuz etkiler.
- Minör: (Yazım hataları, eksik simgeler, düzen sorunları vb.) gibi diğer tüm hatalar.
4) Çevre:
Bir Hata belirli bir ortamda ortaya çıkabilir, başkalarında görünmeyebilir. Örneğin, bazen web sitesini çalıştırırken bir hata ortaya çıkıyor Firefoxveya yalnızca bir cihazda çalışırken bir uygulama arızası Android cihaz ve iPhone'da iyi çalışıyor.
Bu hata raporları yalnızca tarayıcılar arası veya cihazlar arası testlerle belirlenebilir. Bu nedenle, hatayı bildirirken KG'ler, hatanın bir veya daha fazla belirli ortamda mı gözlemleneceğini belirtebilmelidir.
5) Özet:
Ancak hata raporuna yalnızca Başlığın eklenmesi amaca hizmet etmemektedir. Yani Başlığınız yeterli değilse kısa bir rapor özeti ekleyebilirsiniz.
Hatanın ne zaman ve nasıl oluştuğunu da içerecek şekilde mümkün olduğunca az kelimeyle özetiniz. Başlığınız ve hata açıklamanız da aramalarda kullanılmalıdır, bu nedenle önemli anahtar kelimeleri kapsadığınızdan emin olmalısınız.
Örnekler:
- kötü: "Testlere bir şeyler eklemeye çalışıyordum ama bunu yaptığımda veya düğmeye tıkladığımda hiçbir şey çıkmadı."
- Şunun için iyi: "[ÜRÜN] ürününü alışveriş sepetine eklemeyi denediğimde ancak belirli ürüne genel bakış web sayfasında 'ekle' düğmesini tıkladığımda hiçbir şey olmadı."
6) Yeniden oluşturma adımları:
Bir hatayı bildirirken, onu yeniden oluşturma adımlarını belirtmek önemlidir. Ayrıca hataya neden olabilecek eylemleri de eklemelisiniz. Burada genel ifadeler kullanmayın.
İzlenecek adımlar konusunda spesifik olun:
Burada iyi yazılmış bir prosedür örneği verilmiştir:
Adımlar:
- X1 ürününü seçin.
- Sepete ekle'ye tıklayın.
- Ürünü sepetten kaldırmak için Kaldır'a tıklayın.
7) Beklenen sonuç:
Hata raporlarında, teknik görev, test senaryosu sonuçları tasarımı veya test uzmanının görüşüne göre beklenen sonucun tanımlanması önemlidir. Tüm bunlar geliştiricilerin ihtiyaç duyulan bilgiyi hızlı bir şekilde bulmaya odaklanmasına yardımcı olur.
Örneğin:
“Gönder” butonuna tıklandıktan sonra gerekli alanlar kırmızı renkle vurgulanmalıdır.
8) Gerçek sonuç:
Adından da anlaşılacağı gibi bu alan, hatanın gerçek etkisini açıklar. Gerçek sonucun net bir açıklamasını yazmak çok önemlidir.
Örneğin:
“Gönder” butonuna tıklandıktan sonra gerekli alanlar yeşil renkle vurgulanır.
9) Ekler (ekran görüntüleri ve videolar):
Hata raporlarında, görsel olarak görüntülemeniz gerektiğinde bilgileri algılamayı kolaylaştıracak şekilde hata raporlarına dosya eklemek en iyi uygulamadır:
Örneğin:
- Ekran görüntüsü: Ekran görüntüleri programdaki hataları kolayca detaylandırabilir; Hata belirli bir açıklama, daire veya ok görüntüsüyle vurgulandığında kullanışlıdır).
- Video: Bazen hatayı kelimelerle anlatmak zordur, bu nedenle geliştiricinin programdaki kusuru düzeltebilmesi için bir video oluşturmak daha iyidir).
10) Etkilenen Sürüm:
Hatanın rapor edildiği, etkilenen yazılım sürümüdür.
11) Sürümü Düzelt:
Hatanın çözüldüğü yazılım sürümüdür. Dolayısıyla hatayı bildiren QA, sorunun düzeltilip düzeltilmediğini kontrol ettiğinde doğru yazılım sürümünü kullanır.
12) Target versiyon:
Bir hatanın düzeltilmesi gereken hedef sürüm. Dolayısıyla geliştirme ekibi bir hatayı düzeltmeye çalışırken çoğunlukla belirli bir uygulama sürümünü hedefler.
13) Kapanış Tarihi:
Yazılım test ekibi tarafından hatanın kapatıldığı tarihtir. Bir hatayı kapatmak, yazılım testinin hayati ve ayrılmaz bir parçasıdır.
14) Durum:
Yeni bir hata oluşturulduğunda durumu açık olmalıdır. Bundan sonra Devam Ediyor, Düzeltildi, Çalıştırılıyor, Yeniden Açıldı vb. aşamalardan geçer.
Hata Raporu Yazma İpuçları
Etkili bir hata raporu yazarken hatırlamanız gereken bazı önemli ipuçları:
- Hata raporları oluştururken spesifik olun. Yararsız veya alakasız gerçekleri eklemediğinizden emin olun.
- Hatayı tespit ettiğiniz anda derhal bildirmelisiniz.
- Geliştiricinin sorundaki hataları ayıklamak için gerçekleri ve bilgileri kullanmasını sağlamak amacıyla raporu ayrıntılı bir şekilde hazırlayın.
- Doğrulama için aynı hata oluşumunu diğer benzer modüllerde test etmelisiniz.
- RevHata raporunu göndermeden önce en az bir kez görüntüleyin.
- Hata raporunun yalnızca bir hatanın açıklamasını içerdiğinden emin olmalısınız.
- Son olarak, bir konuda kararsız kaldığınızda Proje Yöneticisinden yardım istemekten korkmamalısınız.
Hata Raporlama araçları
Manuel olarak gerçekleştirilen hata raporlama işlemi artık piyasada bulunan çeşitli hata raporlama araçlarıyla da gerçekleştirilmektedir.
- JİRA
- Zoho Hata Takibi
- Bugzilla
Detaylı incelememizi inceleyebilirsiniz. en iyi hata raporlama aracı.
Hata raporu yazarken Sık Karşılaşılan Sorun ve Çözümü:
Hata raporu yazarken karşılaşılan bazı yaygın sorunlar ve bunların çözümleri şunlardır:
| Hata Raporu Örneği | Sorun |
|---|---|
| 2 ile 3 çarpıldığında cevap pozitif olacaktır. | Örnek değil, modeli bildirin. |
| Bunu önlemek için yeni bir öğe eklenirken liste alfabetik olarak sıralanacaktır. | Yalnızca sorunun ne olduğunu açıklamayın |
| Örneğin: Olmak için tarayıcınızı açmanız ve sitenin URL'sini yazmanız gerekir. İlk alan olan 'kullanıcı adı'nın yanlış yazıldığını göreceksiniz. |
Daima asıl konuya odaklanın (Asla hikayeyi anlatmayın!). |
| Raporda müşterinin adı yanlış yazılmıştır. Öncelik: Yüksek, Önem Derecesi: Yüksek | Öncelik ve önem derecesini asla karıştırmayın. |
| Vergi hesaplama formülü YANLIŞ !!?? | Büyük harf, kırmızı harfler, kırmızı daireler, '!' kullanılmaz, |
| Ana sayfa Ul tasarımının iyi olduğunu düşünmüyorum. | Kararınızı kullanmayın. |
| Belirsiz açıklama örneği: Bugünkü tartışmamızla ilgili olarak lütfen bu sayfa için gerekli işlemi yapın. | Açıklamanızı herkes için anlaşılır hale getirin. |
| Sayfa arka planı mavi, turuncu veya yeşil olmalıdır veya siyah veya beyaz yapabilirsiniz.
Web geliştirme ve tasarım ekibinden neye ihtiyaç duyulduğu belli olmadığı için bu iyi değil |
Seçenekleri en aza indirin |
| Vergi hesaplama formülü bazen beklendiği gibi çalışmıyor. | Altın kural: 'Bazen' kelimesini kullanmayın. |
Hata Raporu Örneği
Aşağıda hata raporunun küçük bir örneğini bulabilirsiniz:
[HESABIM] Güncelle düğmesinin üzerine fareyle gelindiğinde altı çizili görüntüleniyor.
Descriptiyon: Hesabım bölümündeki Güncelle butonunun üzerine fareyle geldiğimizde alt çizgiyi kaldırmamız gerekiyor.
Bağlantı: http://test.com/mv-account/
Tarayıcı/İşletim Sistemi: Chrome 25. OSX Yosemite 10.10.2
Yeniden üretme adımları:
1. www.test.com'a gidin
2. Oturum açma kimlik bilgilerinizle oturum açın
3. Hesabım'a gidin
4. Fareyi Güncelle düğmesinin üzerine getirin
Gerçek sonuç: bir alt çizgi var.
Beklenen Sonuç: alt çizgi yok.
Giriş Verileri: test@test.com / mysecretpass12
Hata raporu yazarken hatalardan kaçınılmalıdır
Hata raporu yazarken kaçınmanız gereken bazı önemli hatalar şunlardır:
- Memnuniyetsizliğinizi yazmayın ve asla kişisel duygularınızı yazmayın.
- Gönderinizi çok sayıda ifadeyle aşırı doldurmanız göreve odaklanmak isteyen insanları rahatsız ediyor.
- Gönderinizi asla ünlem işaretleriyle aşırı yüklemeyin; işi hızlandırmaz.
- Kimse gücenmek istemez. Motivasyonu yok eder ve konunun gerçekleşmesini yavaşlatır.
