Was gehört in einen perfekten Bug Report? - Qcademy (2024)

Als Adressaten der Fehlerbeschreibung müssen wir verschiedene Rollen berücksichtigen.

1. DieEntwickler:in, welche die Korrektur umsetzen soll, möchte im Detail verstehen, was als falsch beurteilt wird und wie der Zustand hergestellt werden kann, in dem der Fehler auftritt.
2. Die Projektleiter:in oder dieProduct Owner:inmuss verstehen, wie kritisch der Fehler für den Betrieb der Software ist und welche Folgeprobleme er verursacht. Außerdem setzt sie den Fehler noch in den Kontext des Projekts und der anderen Aktivitäten, die noch umzusetzen sind.

Für alle, die den Fehler bearbeiten, ist es wichtig, zu wissen, in welcher Version der Software der Fehler beobachtet wurde. Es kann die produktive Version der Software sein, oder eine Version, die noch nicht in der Produktion ist, sondern sich erst noch im Test befindet. Weitere wichtige Information ist, das Wissen um die Fehlerschwere, und die Auftrittshäufigkeit.

Die Fehlerschwere

Mit der Fehlerschwere beschreiben wir den Schaden, den ein Fehler verursachen könnte, wenn er weiterhin bestehen bleibt. Hierfür werden Fehler in Kategorien zur Fehlerschwere (engl. severity) eingeteilt:

1. Blocker
2. Kritisch
3. Hauptfehler
4. Nebenfehler
5. Trivialer Fehler

Wofür benötigen wir die Fehlerschwere?

In einem Satz und vereinfacht drückt die Fehlerschwere aus, wie „schlimm“ der Fehler ist. Die Fehlerschwere bildet das Produkt aus drei Informationen ab:

• Der Kritikalität des einzelnen Fehlers,
• der Auftrittswahrscheinlichkeit des Fehlers und
• der erwarteten Anzahl Transaktionen / Benutzer, die betroffen sind.

Zur Erläuterung:
Ein Fehler, der einen sehr großen Schaden verursacht, aber in der Produktion nie oder nur in 0.001 % der Fälle auftritt, ist wirkt auf den ersten Blick gar nicht so schlimm. Denkt ihr jetzt aber an Zahlungsverkehrsanbieter, der täglich 100 Mio. Transaktionen verarbeitet wie das SEPA Zahlungssystem für den Massenzahlungsverkehr, sieht das schon ganz anders aus. Hier wurden 2020 ca. 46 Milliarden Transaktionen verarbeitet, mit einem durchschnittlichen Betrag von ca. 780 € pro Transaktion.

Ein Fehler mit einer Eintrittswahrscheinlichkeit von 0,001 % kann in diesem System an jedem Tag, den er im System ist, einen Schaden von ca. 997.000 € verursachen oder anders es sind täglich ca. 1200 Zahlungen von dem Fehler betroffen.

(Quelle:SEPA Clearing Statistik 2020)

In jedem Unternehmen und Kontext werden diese Kategorien konkretisiert und beschrieben. Ein Beispiel für eine Kategorisierung der Fehlerschwere findet ihr hier

(Die Beschreibung selbst wirft für den Tester auch wieder eigene Fragen auf, wie “Welche sind die Hauptfunktionen und was ist eine unwichtige Funktion”. Diese Fragen müssen jeweils im Kontext der zu bewertenden Software beantwortet werden und es gibt immer wichtigere und unwichtigere Funktionen. Für den Moment wollen wir es dabei belassen, dass Softwaretester:innen wissen müssen, dass es Funktionen gibt, die unterschiedlich wichtig für den Einsatz und Erfolg der Software sind.)

Die Auftrittshäufigkeit wird meist beschrieben und nicht fest einkategorisiert. Ein paar generelle Fragen helfen euch, dies zu beurteilen.

• Wie viele Kunden sind betroffen. (Alle / ein Großteil / ein paar / kaum einer)
• Wie viele Transaktionen können betroffen sein (100 % / 50 % / 1 %)

Für die Reparatur der Software sind alle Informationen nötig, die zu beschreiben, was ihr beobachtet habt und wie ihr den Zustand herstellen konntet. Eine gute Fehlerbeschreibung vereinfacht die nötigen Analysen und grenzt die zu analysierenden Bereiche in der Software ein.

Was muss in die Bugbeschreibung rein?

Vorab noch ein Tipp: In jedem Bug Report soll nur genau ein Effekt beschrieben werden. Wenn ihr mehrere Beobachtungen habt, dann schreibt für jede Beobachtung einen eigenen Bug.

Mit den 6Ws könnt ihr die Beschreibung kurz zusammenfassen:

Wer hatWas mitWelcher Softwareversion beobachtet?

WelchesVerhaltenwurde erwartet?

Wie kann man Fehlverhalten nachstellen?

Welche Belege gibt es für das Fehlverhalten?

In eurem Projekt bietet es sich an, mit den Entwickler:innen zusammen eine Vorlage für einen Fehlerbericht zu vereinbaren, damit alle, die Fehler finden, diese auch so beschreiben, dass sie nachvollzogen und korrigiert werden können.

Der Fehlerlebenszyklus

Fehler durchlaufen von der Erfassung bis zur Behebung einen standardisierten Lebenszyklus. Das heißt, sie starten in einem definierten Zustand und enden in einem definierten Zustand. Dazwischen sind mehrere Übergänge erlaubt. Dieser Fehlerlebenszyklus hilft uns zu jeder Zeit zu wissen, wer als Nächstes etwas mit dem Fehler tun muss.

(In vielen Projekten verläuft der Lebenszyklus nicht rein linear, sondern es kann auch andere Zustandswechsel geben von z.B. von “testbar” nach “in Arbeit”, wenn die Fehlerkorrektur nicht ausreichend war.)

In den meisten Projekten werden die Fehler in einem System geführt und in diesem werden noch ein paar andere Daten erfasst und mitgeführt, um die Daten verwalten zu können und um automatische Auswertungen erstellen zu können. In der nachfolgenden Liste findet ihr einige Eigenschaften, die für einen Bug wichtig sind – je nachdem wie in eurem Kontext gearbeitet wird, kann die Menge der Eigenschaften hiervon abweichen. Fangt ihr aber bei null an und müsst in eurem Umfeld komplett neu beschreiben, was zu einem Bug alles an Informationen gehört, könnt ihr mit diesen Angaben sehr gut starten.