İyi bir hata veritabanı oluşturma adımları

Hata veritabanını korumak her proje için önemlidir. Aşağıdakileri hata veritabanında saklamak için alışkınım

• Düzenlenme tarihi saati
• Kime atandı
• Çözülüp çözülmediği
• Çözülmüşse, tarih tarihini çözdü

Bunlar iyi bir hata veritabanı korumak için yeterli mi?

İyi bir hata veritabanı aşağıdakilere sahip olabilir

// İlgili Tarih Saat

• Hatanın yayınlanma tarihi
• Beklenen düzeltme / çözme tarihi saati
• Çözülmüşse, tarih tarihini çözdü

// + Kime Atandı

• Atanan (tarafından tespit edilen)
• Atandı

// Hata davranışı

• Gözlemlenen (buggy) davranış
• Ekran Görüntüsü (Mümkün)
• Hatayı yeniden oluşturmak için adımları tamamlayın
• Beklenen davranış

// Öncelik

• Hatanın önceliği

// Bağlantı, Durum ve Diğerleri

• İlgili hataların bağlantısı
• Hatanın durumu
• Çözülüp çözülmediği
• O zaman çözülürse, açıklama ile nasıl çözülür

EDIT: Ben de tavsiye etmek istiyorum

• Hata hangi revizyonda / branşta keşfedildi
• Hangi düzeltme / dalda hata düzeltildi

EDIT: @ jgauffin'ın yorumunu beğendim

• Düzeltmez, Hata değil, Çoğalt, Çözüldü

EDIT: İyi bir hata veritabanı sistemi de korur

• Sorumluluk atama matrisi

Orada olabilir özel alanlar bir dizi proje ihtiyaçlarına bağlı olarak giriş yapmanız gerekebilir. Aşağıdaki listeyi de dikkate almanız gerekebilir:

• DateTimeHata / Hata Sorunu
• Hata açıklaması - yeniden oluşturma adımları.
• Bulunduğu ortam (Dev, QA, QC, Staging, Prod)
• Sorunun ekran görüntüsü
• Kim kaydetti (tarafından tespit edildi)
• Kime atanır (tarafından atanır)
• Böceğin Şiddeti (Düşük, Orta, Yüksek)
• Beklenen çözünürlük DateTime
• Durum Triyajı (Önerilen, Devam Ediyor, Çözüldü, Kapalı)
• Hata Kapalı DateTime- bir hata çözüldüğünde ve kapatıldığında
• Test edilecek (test edilen)

Düzenleme: İzlenecek değeri olan ortak bilgilerin çoğu Bugzilla gibi yazılımlarda iyi tanımlanmıştır . Bugzilla, başlangıçta Mozilla projesi tarafından geliştirilen ve kullanılan ve Mozilla Kamu Lisansı altında lisanslanan ve ÜCRETSİZ olan Web tabanlı genel amaçlı bir hata izleme ve test aracıdır . Bunları birincil örnek olarak almanızı ve proje ihtiyaçlarınıza göre genişletmenizi şiddetle tavsiye ederim .

Yararlı alanların çoğu zaten diğer cevaplar tarafından kapsanmış gibi görünüyor, ancak yararlı bulduğum bazıları:

• Hangi revizyon / branşta hata bulundu.
• Hangi revizyon / branşta düzeltildi.

Bu, hatanın hangi tarih / saatte keşfedildiğinden / düzeltildiğinden biraz daha belirgindir.

Yazılımınız birkaç platformda (OS veya donanım) çalışıyorsa, hatanın oluştuğu platformları listeleyen bir alan da isteyebilirsiniz.

Ancak, hata veritabanını korumak için hangi alanları içermesi gerektiğinden daha fazlası vardır. Tabanı nasıl kullandığınızı da düşünmeniz gerekir.

Açık / çözülmemiş hataların sayısını mümkün olduğunca düşük tutmaya çalışın. Bu açık görünebilir, ancak en azından daha büyük projeler için beklenenden daha zor olabilir. Çoğunlukla, tekrarlanamayan veya eksik bilgi asla sorunun orijinal göndericisi tarafından sağlanmayan sorunları kapatmaktan çok korkar. Ayrıca sonsuza dek süren ve yazılımın eski versiyonlarında görülen hatalar etrafta bırakılmamalıdır. Bu veritabanı gerçek sorunları olabilir veya olmayabilir sorunları ile büyümesini sağlar ve gelişimi yavaşlatır.

Sıklıkla bir hatanın geçmişini görmeniz gerekir _ çözülebilir, sonra yeniden açılabilir, sonra tekrar çözülebilir, vb. (yeniden) her açıldığında bir hatanın tarihçesi. Tablo, hata tablosu ile birebir ilişki içerisindedir ve muhtemelen aşağıdaki gibi alanlara sahip olacaktır:

• Açılış Tarihi
• Açan
• Çözümlenme Tarihi
• Çözen
• Harcanan zaman
• Nasıl çözüldü
• vb.

Özellikle büyük bir ekipte çalışıyorsanız, hatanın kime ve ne zaman (yeniden) atandığını izlemek için de benzer bir tabloya ihtiyacınız olabilir.

Ayrıca mevcut sistemlere de göz atmanızı öneririm. IMHO Jira en iyi sorun izleme sistemlerinden biridir. Çok zengin özelliklere sahiptir ve bunlardan bazılarını kendi sisteminiz için bir rehber olarak kullanabilirsiniz.

Hata izleme süreci, veriler kadar önemlidir. Aşağıdakileri de düşünmeye çalışın:

• Kullanıcılar hatayı nasıl bildirir?
• Hatayı depoya kim girer?
• Hatanın var olduğunu kim doğrulayabilir?
• Hatanın giderildiğini kim doğrulayabilir?
• Son kullanıcıyı hatanın giderildiğini kim bildirir?

Ekibinizdeki herkesin (son kullanıcılar da dahil olmak üzere sorumluluklarını bilmesi için) bir RACI Şeması oluşturun . Bunu uygun veri giriş teknikleri ile birleştirin ve ekstra çaba ile çok daha fazla değer göreceksiniz.