Schritte zum Verwalten einer guten Fehlerdatenbank

Die Pflege der Fehlerdatenbank ist für jedes Projekt wichtig. Ich bin es gewohnt, das Folgende in der Fehlerdatenbank zu speichern

• Ausstellungsdatum Uhrzeit
• Wer ist zugeordnet
• Ob es gelöst wurde oder nicht
• Wenn dann gelöst, gelöst Datum Datum

Reichen diese aus, um eine gute Fehlerdatenbank zu unterhalten?

Eine gute Fehlerdatenbank kann Folgendes enthalten

// Datum Uhrzeit

• Ausgabedatum Uhrzeit des Fehlers
• Voraussichtliche Fix / Solve-Datums- und Uhrzeit
• Wenn dann gelöst, gelöst Datum Datum

// Zugewiesen von + An

• Zugewiesen von (erkannt von)
• Zugewiesen an

// Fehlerverhalten

• Beobachtetes (fehlerhaftes) Verhalten
• Screenshot (ist möglich)
• Führen Sie die Schritte aus, um den Fehler zu reproduzieren
• Erwartetes Verhalten

// Priorität

• Priorität des Fehlers

// Link, Status und andere

• Link verwandter Fehler
• Status des Fehlers
• Ob es gelöst wurde oder nicht
• Wenn dann gelöst, wie mit Erklärung gelöst

EDIT: Ich möchte auch empfehlen

• In welcher Revision / in welchem ​​Zweig wurde der Fehler entdeckt?
• In welcher Revision / Branche wurde der Fehler behoben

EDIT: Ich mag @ jgauffins Kommentar

• Wird nicht behoben, kein Fehler, duplizieren, behoben

BEARBEITEN: Ein gutes Bug-Datenbanksystem bleibt ebenfalls erhalten

• Verantwortungszuweisungsmatrix

Abhängig von den Projektanforderungen müssen möglicherweise mehrere benutzerdefinierte Felder protokolliert werden. Ich habe die folgende Liste erstellt, die Sie möglicherweise ebenfalls berücksichtigen müssen:

• Problem DateTimevon Bug / Defect
• Beschreibung des Fehlers - Schritte zum erneuten Erstellen.
• Umgebung, in der es gefunden wurde (Dev, QA, QC, Staging, Prod)
• Screenshot des Problems
• Wer hat es protokolliert (erkannt von)
• Wem wird es zugewiesen (zugewiesen von)
• Schweregrad des Fehlers (niedrig, mittel, hoch)
• Erwartete Auflösung DateTime
• State Triage (vorgeschlagen, in Bearbeitung, gelöst, geschlossen)
• DateTimeFehler ist geschlossen - wenn ein Fehler behoben und geschlossen ist
• Zugewiesen, um getestet zu werden (getestet von)

Bearbeiten: Die meisten allgemeinen Informationen, deren Wert verfolgt werden muss, sind in Software wie Bugzilla gut beschrieben . Bugzilla ist ein webbasiertes Allzweck- Bugtracker und Testwerkzeug ursprünglich vom Mozilla - Projekt entwickelt und verwendet wird , und unter der Mozilla Public License - lizenziert und ist KOSTENLOS . Ich würde dringend empfehlen , sie als primäres Beispiel zu nehmen und sie auf Ihre Projektanforderungen auszudehnen.

Die meisten nützlichen Felder scheinen bereits von anderen Antworten abgedeckt worden zu sein, aber einige, die ich nützlich finde, sind:

• In welcher Revision / in welchem ​​Zweig wurde der Fehler entdeckt?
• In welcher Revision / Branche wurde es behoben.

Dies ist etwas spezifischer als zu dem Zeitpunkt, zu dem der Fehler entdeckt / behoben wurde.

Wenn Ihre Software auf mehreren Plattformen (Betriebssystem oder Hardware) ausgeführt wird, möchten Sie möglicherweise auch ein Feld, in dem die Plattformen aufgelistet sind, auf denen der Fehler auftritt.

Die Verwaltung einer Fehlerdatenbank umfasst jedoch mehr als nur die Felder, die sie enthalten sollte. Sie müssen auch überlegen, wie Sie die Basis verwenden.

Versuchen Sie, die Anzahl offener / ungelöster Fehler so gering wie möglich zu halten. Dies mag offensichtlich erscheinen, kann jedoch zumindest bei größeren Projekten schwieriger als erwartet sein. Ich sehe oft Leute, die zu viel Angst haben, Probleme zu schließen, die entweder nicht reproduzierbar sind oder bei denen der ursprüngliche Einreicher des Problems niemals Informationen zur Verfügung stellt. Auch Fehler, die schon immer herumliegen und zuletzt in alten Versionen der Software gesehen wurden, sollten nicht herumliegen. Dadurch wächst die Datenbank mit Problemen, die möglicherweise echte Probleme sind oder nicht, und verlangsamt die Entwicklung.

Oft müssen Sie den Verlauf eines Fehlers anzeigen. Möglicherweise wird er behoben, dann wieder geöffnet, dann erneut behoben usw. Zusätzlich zu den bereits vorgeschlagenen Fehlern würde ich Ihnen empfehlen, eine separate Tabelle zu haben, um den Überblick zu behalten der Geschichte eines Fehlers jedes Mal, wenn er (wieder) geöffnet wird. Die Tabelle würde in einer Eins-zu-Eins-Beziehung zur Tabelle der Fehler stehen und wahrscheinlich Felder wie:

• Eröffnungsdatum
• Geöffnet von
• Aufgelöstes Datum
• Gelöst von
• Zeitaufwand
• Wie wurde gelöst
• etc.

Möglicherweise benötigen Sie auch eine ähnliche Tabelle, um zu verfolgen, wem und wann der Fehler (neu) zugewiesen wurde, insbesondere wenn Sie in einem großen Team arbeiten.

Ich schlage auch vor, dass Sie sich vorhandene Systeme ansehen. IMHO Jira ist eines der besten Issue-Tracking-Systeme. Es verfügt über sehr umfangreiche Funktionen, von denen Sie einige als Leitfaden für Ihr eigenes System verwenden können.

Der Prozess der Fehlerverfolgung ist genauso wichtig wie die Daten. Versuchen Sie auch über Folgendes nachzudenken:

• Wie melden Benutzer den Fehler?
• Wer gibt den Fehler in das Repository ein?
• Wer kann bestätigen, dass der Fehler vorliegt?
• Wer kann bestätigen, dass der Fehler behoben ist?
• Wer informiert den Endbenutzer, dass der Fehler behoben ist?

Erstellen Sie ein RACI-Diagramm, damit jeder in Ihrem Team (einschließlich der Endbenutzer) seine Verantwortlichkeiten kennt. Kombinieren Sie dies mit geeigneten Dateneingabetechniken, und Sie werden mit dem geringen zusätzlichen Aufwand viel mehr Wert sehen.