Test Sürecinde Hataların Raporlanması (Bug / Defect Reporting)
Agile proje yönetim modelinde development sonrası bulunan bugların raporlanması önemlidir. Raporlanan bug’ın anlaşılır, açık ve net olması fixleme maliyetini doğrudan etkiler. Kısacası İyi İçerik, İyi Sonuç getirir.
Jira, Trello, Wrike, Gitlab vs. gibi proje yönetim toollarında bug raporlamayla ilgili en çok dikkat edilmesi gereken 6 detay;
- Title (Summary) / Başlık
- Environment / Ortam
- Steps to reproduce / Test adımları
- Actual Result / Karşılaşılan sonuç
- Expected Result / Olması gereken sonuç
- Proof (screenshots, videos, text) / Kanıt (Ekran kaydı, ekran görüntüsü, request/response json’ları vs.)
Title (Summary) / Başlık
Başlık okunduğunda sorunun ne olduğu anlaşılmalıdır. Bug başlığı, bug’ın anlaşılırlığı için önemlidir. Bug başlığı gerektiğinde uzunca yazılabilir.
Environment / Ortam
Bug’ın tespit edildiği koşullar mutlaka belirtilmelidir. Bugfix öncesi logların incelenmesi için ortam bilgilerine ihtiyaç duyulacaktır. Environment altında verilebilecek bilgiler;
-Ortam( Test, Production)
-Tarayıcı(Chrome, Firefox)
-Cihaz(Desktop, Mobil)
Steps to Reproduce / Test adımları
Bug’ın tespit edildiği case taskın içerisine step by step eklenmelidir. Bugfix yapacak developer bu sayede ilgili adımları gerçekleyerek logları inceleyebilecek ve bug’ın kaynağını tespit edebilecektir. Ayrıca bug’ın çözülmesinden sonra bug’ın çözülüp çözülmediğini, bug taskını açan qa dışındaki bir qa’in test etmesi gerekirse taskın içerisine eklenen test adımları sayesinde kolayca testi koşabilecektir.
Actual Result / Karşılaşılan sonuç
Taskın içerisine eklenmiş olan test adımları sonucunda karşılaşılan bug anlaşılır, doğru, açık ve net bir şekilde yazılmalıdır. Ayrıca bug’ın tekrar edilip edilemediği yazılmalıdır.
Expected Result / Olması gereken sonuç
Taskın içerisine eklenmiş olan test adımları sonucunda beklenilen sonuç yazılmalıdır. Olması gereken sonuç aslında bug değilse nasıl çalışmalı sorusunun cevabıdır. Analiz dokümanı ve test senaryolarından yararlanılarak beklenilen çıktı yazılmalıdır.
Proof / Kanıt
Tespit edilen bug’ın fixlenmesi için developer’ın ihtiyacı olan log kaydı, crash zamanı ve bug’ın tekrarlanması için test esnasında kullanılan test datası eklenmelidir. Test datasının değişkenliği, alternatif test dataları ya da ihtiyaç durumunda test datasının update edilmesi için iletişime geçilecek ekip bilgisi de eklenmelidir.
Yaşanılan bug eğer ekran görüntüsü veya video kaydı ile kayıt altına alınabiliyorsa taskın içerisine mutlaka eklenmelidir. Ekran görüntülerinde hatalı alanın işaretlenmesi ve küçük notlar girilmesi bugfix için kolaylaştırıcı olacaktır.
Dikkat Edilmesi Gereken Diğer Konular
Hatanın önceliği yazılımcıya iletilmelidir.
Asla bir bug içerisine birden fazla problem girilmemelidir. Bug taskının kapanamamasına, uzun süre açık kalmasına sebep olabilir. Tek bir bug için bir bug taskı açmak karışıklık ve diğer problemlerin göz ardı edilmesi, unutulması gibi sorunların önüne geçilecektir.
Aktarım dilinde kullanılan terimler yazılım jargonuna uygun olmalıdır.
Örn: Buton, link, textbox, radio button, checkbox, endpoint, request, response vs.
History ve Comment bölümünü aktif olarak kullanılmalıdır. Bugfix sonrasında taskı kapatmadan önce yapılan değişiklik ile ilgili comment girilmesini developerdan istenmelidir.
