Das ideale Bugticket und seine Rolle in der Softwarequalitätssicherung

Heute beschäftigen wir uns mit dem idealen Bug-Ticket.

Das ideale Bugticket existiert nicht… denn der Wunsch aller Software-Entwickler – und das schließt die Qualitätssicherung mit ein – ist eine fehlerfreie Software.
Da dieser Wunsch wohl ein Traum bleiben wird, wollen wir uns mit der Frage befassen, welche Angaben ein solches Bugticket umfassen sollte.

 Angaben im idealen Bugticket

  • Überschrift – die Überschrift sollte präzise auf den ersten Blick die Auswirkung und Ursache eines Fehlers darstellen.
    Ein schlechtes Beispiel wäre wohl „Datenverlust in Applikation“
    Gut hingegen „Datei wird nicht überschrieben, wenn Button Speichern gedrückt wird“
  • Die Beschreibung – sie sollte detailliert erklären, was der konkrete Fehler ist. Außerdem muss sie eine Beschreibung enthalten, wie der Fehler reproduziert werden kann. Welche konkreten Schritte sind zu unternehmen.
    Dies ist zwingend erforderlich für den Entwickler, der den Fehler finden soll, und für den Tester, der nachher die Behebung des Fehlers feststellen muss.
    Ein Fehler, der nicht reproduzierbar ist, kann nicht behoben werden!
    Vergessen Sie nicht zu erwähnen, in welcher Version der Fehler auftrat. Eine Behebung findet manchmal Wochen oder Monate später statt, und der Fehler ist auf dieser Version dann schon „zufällig“ durch jemand anderen behoben worden.
  • Arbeiten Sie im Projekt mit einer Komponenten-Einteilung, oder sonstigen Zuweisung?
    Dann tun Sie Ihren Kollegen einen Gefallen, und wählen Sie gleich die richtige Komponente aus. Eine falsche Komponente sorgt im Zweifelsfall dafür, dass ein Ticket nicht bearbeitet werden kann.
  • Haben Sie eine bestimmte Konfiguration Ihres Programms, die erforderlich ist, um den Fehler zu reproduzieren?
    Nutzen Sie die Möglichkeit, Dokumente an das Bugticket anzuhängen.
    Dasselbe gilt für Logdateien, auch diese sind häufig hilfreich bei der Fehlerfindung
  • Einteilung eines Fehlers in Bezug auf die Schwere:
    In manchen Ticketing-Systemen ist nur es möglich, eine Wahl zwischen „Hoch“, „Mittel“, „niedrig“ zu treffen.
    Andere Systeme hingegen erlaube eine Einteilung in 2 Dimensionen: Dringlichkeit und Schwere des Fehlers. Diese Einteilung werden wir zu einem späteren Zeitpunkt detailliert behandeln.An dieser Stelle nur soviel: Die Dringlichkeit gibt an, wie schnell ein Fehler behoben werden muss („spät“, „sofort – die Testabteilung kann sonst nicht weiter arbeiten“). Die Schwere des Fehlers hingegen gibt an, mit welchen Folgen ein Fehler verbunden ist (kritischer Fehler – „Datenverlust“, kosmetischer Fehler – „Tippfehler“).Auch ein Tippfehler kann ein release verhindern, zum Beispiel, wenn die Email-Adresse des Unternehmens falsch eingetragen ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.