fbpx

Was gehört in einen perfekten Bug Report?

Wir führen euch hier in Bug Reports ein und helfen euch dabei zu verstehen, was in einen Bug Report hineingehört, sodass er von euren Kollegen geschätzt wird und ihr ihn nicht zurückbekommt, weil er unverständlich oder unvollständig ist.

Wenn wir als Software-Tester:innen Software testen, dann machen wir dies immer mit dem Ziel, möglichst viele Fehler zu finden, die den Wert der Software mindern.
Dabei hilft es, uns immer wieder daran zu erinnern, dass “jede” Software Fehler hat. Manche Fehler sind bekannt, andere wurden noch nicht entdeckt.
Aber der Grundsatz “jede Software hat Fehler” ist für uns als Software-Tester:in eigentlich der wichtigste Grundsatz für unsere tägliche Arbeit.

Was ist ein Bug?

Als Bug oder Softwarefehler bezeichnet man gemeinhin eine Funktion in einer Software, die nicht so funktioniert, wie sie soll.

Eine andere Definition, aus der “Context Driven School” lautet: Ein Fehler mindert den Wert einer Software – für eine Person, für die diese Software oder diese Funktion wichtig ist.

Anhand einer guten Fehlerbeschreibung kann das beobachtete Fehlverhalten der Software verstanden und die Priorität der Fehlerbehebung bestimmt werden. Daher ist eine gute Fehlerbeschreibung wie eine gute Visitenkarte für jede:n Tester:in. 

software-tesint-bug-report

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

  1. Die Entwickler: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 die Product Owner:in muss 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

 

Fehlerschwere Beschreibung
Blocker

Die Software kann nicht genutzt werden, weil ihre Hauptfunktionalitäten für den Benutzer nicht nutzbar sind.
Beispiel:

 

 

 

 

 

 

 

 

  • Software lässt sich nicht installieren.
  • Login ist nicht möglich.
  • Bezahlen ist nicht möglich
Kritisch Der Fehler verhindert die Nutzung einer wichtigen Funktionalität.
Hauptfehler Der Fehler beeinträchtigt die Nutzung einer wichtigen Funktionalität, die Funktion kann aber über Umwege noch genutzt werden.
Der Fehler verhindert die Nutzung einer unwichtigen Funktionalität.
Nebenfehler Der Fehler beeinträchtigt die Nutzung einer unwichtigen Funktionalität, die Funktion kann aber über Umwege noch genutzt werden. 
Trivialer Fehler Schönheitsfehler oder Beeinträchtigung, die aber umgangen werden kann.

 

(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 hat Was mit Welcher Softwareversion beobachtet?
Welches Verhalten wurde 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.

wann-lohnt-sich-eine-umschulung

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.

Bug-Lebenszyklus.

(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.)

Status

Beschreibung

Neu

Der Fehler wurde erfasst und kann beurteilt werden.

Offen

Der Fehler wurde beurteilt und soll bearbeitet werden.

In Arbeit

Der Fehler ist in der Bearbeitung.

Testbar

Der Fehler wurde vom Entwickler bearbeitet und als repariert markiert. Er kann nun mit einer neuen Version geprüft werden.

Geschlossen

Der Fehler wurde bearbeitet und behoben oder es ist kein Fehler und muss nicht weiter bearbeitet werden.v

 

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. 

Feld Beschreibung
ID Eindeutige Identifikation des Fehlers im System
Titel Kurzer, eindeutiger Titel, der den Fehler möglichst konkret zusammenfasst.
Beschreibung

Vollständige Beschreibung der Schritte, die für die Nachstellung des Fehlers nötig sind. Schreibe hierfür die kompakteste Liste von Schritten, die nötig sind, um den Bug zu reproduzieren.


Gib die Daten, die für die Nachstellung des Fehlers genutzt wurden.
Jedes Detail kann hierbei nützlich sein. z. B.

  • Welcher Benutzer hat sich eingeloggt, ggf. welche Benutzerkategorie
  • Welche Produkte hat er im Warenkorb
  • Welche Sprache hat der Benutzer ausgewählt

 

Andere Informationen, die relevant sein können:

 

  • Betriebssystemversion
  • Browsertyp und -Version
  • Auflösung
  • Gerätetyp und Version
  • Orientierung (Hochkant, Quer)
Status Der Status eben, wie oben beschrieben.
Priorität Priorität der Bearbeitung des Fehlers durch die Entwicklung. 
Fehlerschwere Die Fehlerschwere, wie oben beschrieben.
Anhänge Screenshots, Logfiles und sonstige Informationen, die den Fehler genauer beschreiben.
Beziehungen Testfälle, Anforderungen, User Storys, andere Fehler im Kontext
Gefunden in Version Version und Buildnummer der Software, in welcher der Fehler beobachtet wurde.
Geschlossen in Version Version und Buildnummer der Software, in welcher die Korrektur des Fehlers festgestellt wurde.
Gefunden am  Datum, an dem der Fehler erstellt wurde (wird meist automatisch erstellt).
Geschlossen am Datum, an dem der Fehler geschlossen wurde (wird automatisch erstellt).
Francesco La Torre

Francesco La Torre

Gründer & Coach Qcademy

Seit 2004 liebe ich es, Menschen für das Softwaretesten zu begeistern. Ich habe schon vielen Quereinsteigern eine neue berufliche Perspektive im Softwaretesten ermöglicht. Ein guter Start in Softwareentwicklungsprojekte ist ein Einstieg ins Software Testing und mit Qcademy werden wir mehr Menschen die Möglichkeit geben, beruflich neue Wege zu gehen und über sich hinaus zu wachsen.