Yazılım Testlerinde Hata Yönetimi ve Raporlama

Merhaba Arkadaşlar,

Yazılım test süreci aşamalarına devam ettiğimiz bu yazımızda hatalar bildirilirken dikkat etmemiz gerekenler ve hata süreci yönetimi konularını ele almaya çalışacağız. Yazılım Test Süreci göz önüne alındığında, yazılım geliştirme yaşam döngüsünün her yerinde hata çıkabilir. Örneğin gereksinimlerin analiz edilmesi belirlenmesi  aşamasında yapılan hataların maliyeti ve etkisi sonraki adımları da etkileyecek hatalardır.  Bu aşamada karşılaşılan hatalardan daha az soruna neden olan hatalar ise yazılım aşamasında yakalanan hatalardır diyebiliriz. Testi yapan kişiler tarafından bulunan defectler (hata) ilgili yazılımcı ile iletişime geçilerek düzeltilir. İşte bu bulunan hatalar ve bunların düzeltilmesi konusunu ele alacağımız hata yönetimi ve raporlama aşamasına artık başlayalım.

Yazılım testlerinde hata yönetimi ve raporlama

Yazılım testlerinde hata yönetimi ve raporlama aşamasında yapılacak test türlerine göre bulduğumuz hataları bildirmemiz gerekir. Yapılan teste göre doğrulama noktasında, beklenen sonuç ile gerçekleşen sonuç arasındaki uyumsuzlukları açık, net bir şekilde ve belirli bir süreç izlenerek geliştiricilere iletiriz. Hatalar düzeltildikten sonra ve testler tamamlandıktan sonra ise bir test raporu ile sonuçları paydaşlarla açık ve anlaşılır olacak şekilde paylaşılır. Yazılım test süreci aşamalarının bu son adımlarında bu iki noktaya değinmeye çalışacağız.

Gereksinimlere göre oluşturulan test senaryoları otomasyon ya da manuel olarak koşulduğunda beklenen sonuç gerçekleşen sonucun uyuşmamasına hata olarak değerlendirebiliriz. Yürütülen bu testler sırasında karşılaşılan bu hatalar ya bir tool kullanılarak (JİRA) ya da sözlü olarak ya da başka bir şekilde geliştiricilere bildirilir ve raporlanır. Bu hatalar incelenip düzeltilmesi sağlanıp teste hazır duruma getirildikten sonra hataya özel “onay testi” ve sistemde diğer yerleri etkileyip etkilemediği kontrolü için “regresyon testleri” gerçekleştirilir. Hata Yönetimi ve raporlama aşamasında, hata raporlama yapılırken test araçları ya da dokümanlardan faydalanılarak raporlama yapılabilir. Testler sırasında saptanan hataların tamamının giderilmesi ya da bitiş kriterlerinin karşılanması durumunda test sonuç raporları hazırlanır.

Hataların Önem Derecesi (Severity)

Testlerde saptanan bir yazılım hatasının önem derecesi, sistemin çalışmasındaki hata etkisinin derecesini belirler. Testler sırasında saptanan hatalar önem derecesine göre kategorilendirilebilir.

Düşük (Low)–>Testlerin ilerlemesine etkisi olmayan minör olarak değerlendirilecek hatalar. Test edilen öğe bu hatalar ile teslim edilebilir.
Orta (Medium)--> Testler devam edebilir. Bu hata ile teslim edilen ürün için daha sonra telafisi mümkün olacak hatalar. Sistemin çalışmasını bozmayan hatalar
Yüksek (High)–>Sistemin çalışmasını etkileyen fakat testlere devam etmeye engel olmayan hatalar. Düzeltilmesi öncelikli olarak değerlendirilecek hatalar
Kritik (Critical)–>Testleri bloklayan devam etmesini engelleyen ve çözülmesi mutlaka gerekli olan hatalar

Hataların Öncelik Seviyesi (Priority)

Testlerde bulunan hatalar analiz edilerek bir önceliklendirme yapılır ve karşılaşılan hatalar için öncelik verilir. Genel olarak testlerin devam etmesini engelleyen kritik derecedeki hatalar için öncelik verilir. Hatalar için öncelik seviyesi aşağıdaki gibi olabilir.

Düşük (Low)–> Sistemin çalışmasında etkisi olmayan, sistem çalışmasına engel olmayan hatalar.
Orta (Medium)–> Sistemin çalışmasını engellemeyen ama düzeltilmesi gerekli ve teslimden sonra telafisi olan hatalar
Yüksek (High)–>Sistemin işleyişini durdurmayan ama çalışmasını etkileyen hatalar
Kritik (Critical)–>Sistemi işleyişini ve çalışmasını engelleyen hatalar. Düzeltilmesi acil olan hatalar

Gereksinimlerde göre oluşturulan test senaryolarında beklenen durum ile gerçekleşen durumların uyumsuz olduğu noktalarda karşılaştığımız hataları yukarıda Önem derecesi ve Öncelik seviyeleri dikkate alınarak hata detayları oluşturulur. Hatalar açılırken bir Proje ya da Talep kapsamında ise belirtilir. Talep tipi olarak hata seçilir. Hata Özeti girilir. Hata özeti açık ve anlaşılır şekilde olmalıdır.

Hata Kaydı Açılması

Hata yönetimi ve raporlama aşamasında, hatalar için öncelik seviyesi seçilir ve hata açıklaması detaylı olarak girilir. Hata açıklamasında test senaryosunda kullanılan data, ortam bilgileri girilmelidir. Test senaryosu adım adım olarak girilir. Beklenen durum ve gerçekleşen durum belirtilir. Ekran görüntüsü ve yapılabiliyorsa video ile desteklenir. Hatayı düzeltecek kişi ataması yapılarak Hata oluşturulur. Hatalar açılırken JİRA( Atlassian tarafından geliştirilen ve hata takibi ve çevik proje yönetimi sağlayan hata izleme aracıdır.),TestRail, HP ALM gibi toolardan faydalanılabilir. Yoksa excelde tablo oluşturularak ya da mail yoluyla geliştiricilere bildirilir.

Hataların açılma süreci

Testler sırasında karşılaşılan hataların açılmasında düzeltilmesine kadar uygun bir süreç izlenir. Bu uygun süreci şu şekilde özetleyebiliriz:Testleri koşan kişilerce tespit edilen hataların ilk önce önem derecesi belirlenir. Kullanılıyorsa bir tool üzerinden Hata Kaydı oluşturulur. Hatanın kime atanacağı belirlenir. Testleri bloklayan durum olmasına halinde çözüm beklenir. Bloklayan bir durum olmadığında diğer test senaryolarına devam edilir. Hatanın atandığı kişi çalışma başlatır. Analist ile ya da tek başına analiz yapılır. Hatanın giderilmesi için gerekli işlemler yapılır.  Hata olduğu kabul edilmeyen durumlarda hata yazılımcı tarafından reddedilir. Hatanın kabul edildiği ve düzeltildiği duruma tekrar testi için testi yapan kişiye atanır. Hata düzeltilmiş ve tekrar testi başarılı ise açılan hata kaydı kapatılır. Hata için yapılan tekrar testi başarısız ise hata kaydı yeniden açılır.

Ek olarak hatalar kendi akışı içerisinde farklı olarak değerlendirilebilir. Örneğin Test ortamında statik test ve dinamik testlerde yakalanan hatalar, prduction(canlı) ortamda bulunan defectler. Test ortamında yakalanan defectlerin müşteriye etkisi yokken canlıda çıkacak defectlerin müşteriye etkisi olmaktadır. Production defectlerini, müşteri sikayetleri, işlemler sırasında karşılaşılan hatalar ve iç müşterilerden gelen problemler olarak adlandırabiliriz. Prdouctionda karşılaşılan defectler için ise ayrı bir süreç ilerletilir. Bu konuyu detaylı olarak diğer yazılarda ele almaya çalışacağım.

Son olarak Yazılım Geliştirme Süreci evreleri dikkate alındığında bu döngü içerisinde hatanın saptandığı yere göre maliyeti farklılık gösterir. Son aşamalarda yakalanacak hatanın maliyeti yüksek olacağından Yazılım Test ve Süreçlerinin önemini arttırır. Bu yüzden Hata Raporlama ve Yönetim konusu için bu yazımızda detaylı olarak vermeye çalıştım. Umarım faydalı olmuştur sonraki yazılarda görüşmek dileğiyle. Yazılım test süreçleri konusuna devam edeceğimiz yazılarımızı takipte kalın 🙂

Sorularınızı Soru – Cevap  bölümünden sorabilirsiniz.