Hata yaşam döngüsü, bulunan her hatanın keşfinden kapatılmasına kadar geçen süreçtir. IT alanında hata yaşam döngüsü, hataların işlenmesini hızlandırmak, riskleri minimize etmek ve çalışmaların şeffaflığını artırmak için sistemleştirilmiştir.
Konu Tarihi:
Erken hata izleme sistemleri sadece hataları kaydetmeyi sağlıyordu. Yazılımın karmaşıklığı arttıkça, hataların durumlarının yapısal izlenmesi ve işlenme aşamalarının tanımlanması ihtiyacı doğdu.
Sorun:
Resmi aşamalar olmadan, hatalar kaybolabilir, "takılabilir" veya kapatılmadan kalabilir; yani giderilse bile. Ayrıca, QA ve geliştiriciler arasında şeffaflığın olmaması nedeniyle yanlış anlamalar olabilir.
Çözüm:
Aşamaların standartlaştırılması (örneğin: Yeni, Açık, Atandı, Devam Ediyor, Düzeltildi, Tekrar Test Edilecek, Kapatıldı, Yeniden Açıldı) ve her aşamadaki işlemlerin tanımlanması, hata işleme sürecini düzenlemeye ve şeffaf hale getirmeye yardımcı olur.
Öne Çıkan Özellikler:
Eğer bir hata test edicide yeniden üretilmiş ama geliştiricide değilse hata kapatılabilir mi?
Hayır, hata her iki taraf tarafından kabul edilmeli ve hata raporunda yazılı adımların takip edilerek yeniden üretilmelidir.
Eğer hata için 'Düzeltmeyecek' cevabı geldiyse ne yapmalıyız?
QA, reddetme nedenini netleştirmelidir. Eğer neden mantıklıysa (düşük öncelik, gereksinimlerle çelişmemesi), hata yorumla kapatılabilir.
QA, eğer hata kapatıldıktan sonra problem tekrar ortaya çıkarsa hatayı yeniden oluşturmak zorunda mı?
Hayır, hatayı 'Yeniden Açıldı' durumuna geçirmek ve yeniden üretim ile ilgili yeni detaylar eklemek yeterlidir.
Şirket, sadece temel hata kaydı işlevselliğini kullanıyordu. Hata düzeltildikten sonra geliştirici onu çözülmüş olarak işaretliyordu, testçi yeniden test yapmıyordu ve hatalar sürüme geri dönüyordu.
Artılar:
Eksiler:
Ekip, sürüm öncesinde zorunlu yeniden test ve kapatma nedenlerinin tanımlandığı standart bir hata yaşam döngüsü uyguladı.
Artılar:
Eksiler: