Während meiner langjährigen Arbeit als Test Lead für viele verschiedene Projekte habe ich unzählige Bugreports gelesen. Aus dieser Erfahrung kann ich sagen, dass ein schlechter Bugreport nicht nur wenig hilfreich, sondern sogar Zeitverschwendung ist, die sich die meisten Projekte wiederum nicht leisten können – besonders heutzutage, da mehr und mehr UnternehmenPipelines zur kontinuierlichen Integration und Produktbereitstellung (CI/CD) implementieren. Es ist für Projektteams ungemein frustrierend, dem Tester mitten in der Sichtung und Priorisierung einen Bugreport aufgrund unklarer oder fehlender Informationen zurückschicken zu müssen.
Ein effektiver Bugreport hingegen vermittelt dem Leser die gebotene Dringlichkeit und erleichtert es dem Team, das Ausmaß des Bugs zu erkennen und entsprechende Prioritäten zu setzen. Dadurch kann das Team entscheiden, wie, wo und wann Ressourcen zur Behebung von Bugs bereitgestellt werden müssen.
Als höchste Priorität werden Probleme eingestuft, die die größte Anzahl von Nutzern betreffen oder ausschlaggebend für die Anwendung allgemein sind, damit diese unverzüglich in Angriff genommen werden können. Die Prioritätsstufe hängt außerdem davon ab, inwieweit sich der potenzielle Bug auf die Kundenerfahrung und/oder das Unternehmensergebnis auswirkt. Selbst wenn der Bug oberflächlich betrachtet relativ unbedeutend erscheint, könnten seine Auswirkungen für den Kunden erheblich größer sein.
Der Job von Testern ist es, Bugs zu finden, klare und präzise Meldungen dazu abzugeben, den Schweregrad des Problems anhand ihres Wissens über die getestete Anwendung zu bestimmen, detaillierte Reproduktionsschritte aufzuführen und unterstützende Hinweise beizufügen. All dies beginnt mit einem passenden Titel für den Bug.
1. Klarer, präziser Titel
Ein effektiver Bugreport identifiziert das Problem bereits im Titel.
„Habe Fehler gefunden“ war wohl der unsinnigste Titel, der mir je zu Gesicht kam. Er sagt weder uns noch dem Kunden etwas. Als Test Lead würde ich einen solchen Bugreport sofort an den Tester zurückschicken, damit er ihn korrigiert.
Ein leidlich gelungener Titel wäre zum Beispiel:
„Laufzeitfehler in Java bei Auswahl von ‚Zur Kasse‘ im Einkaufswagen“
Dieser Titel gibt uns zumindest eine Vorstellung davon, was das Problem ist. Anhand dieses Titels könnte ich die Priorität des Bugs basierend auf seinen Auswirkungen festlegen, vorausgesetzt, ich erhalte genügend Informationen in der Beschreibung. Wenn ich jedoch in verschiedenen Umgebungen teste, gibt mir dieser Titel noch keinen Aufschluss darüber, ob das Problem in einer oder mehreren Umgebungen auftritt. Auch diesen Bugreport würde ich zurückschicken mit der Bitte um zusätzliche Informationen.
Ein effektiver Titel sollte so viele Informationen wie möglich über das Problem enthalten. Diese sollten die Testumgebung, den Testbereich, den Namen und Schritt des Tests sowie das eigentliche Problem beinhalten:
“Web – Zur Kasse – TC 1802 – BUY EGC – Schritt 4 – Laufzeitfehler in Java bei Auswahl von ‘Zur Kasse’ im Einkaufswagen”
Ein kurzer Blick auf den Titel genügt und schon kann ich die Art des Problems und sein Ausmaß einschätzen.
Je nach verwendeter Bugtracking-Software kann es u. U. eine Zeichenbeschränkung für den Titel bei der Eingabe oder in der Schnellansicht der Bugliste geben. Sollte dies der Fall sein, halte die Informationen im Titel so knapp und präzise wie möglich.
Nun da wir einen klaren, aussagekräftigen Titel haben, kommen wir zum nächsten Schritt, der Beschreibung.
2. Detaillierte Definition des Problems
Der Textkörper sollte so viele Einzelheiten wie möglich zu dem Problem enthalten. Hier gilt dasselbe wie für den Titel: „Habe Fehler gefunden“ ist keine hilfreiche Information. Da wir bereits im Titel so präzise wie möglich waren, sollten wir die Beschreibung jetzt nutzen, um das Problem ausführlicher zu beschreiben. Dazu gehören:
- eine Zusammenfassung des Problems in Fach- oder Laiensprache (Letzteres ist vor allem dann hilfreich, wenn sich in der Leserzielgruppe auch nicht-technisch versierte Projektbeteiligte befinden),
- Name/ID des Testfalls, bei dem das Problem auftrat (sehr hilfreich, wenn der Testfall älteren Datums ist und aktualisiert werden muss, um den aktuellen Funktionsstand widerzuspiegeln),
- exakt beschriebene Testschritte, mit denen der Fehler reproduziert werden kann,
- erwartete Ergebnisse (was geschehen sollte),
- tatsächliche Ergebnisse (was tatsächlich geschehen ist).
3. Unterstützende Dokumentation
Wir haben das Problem nun im Detail beschrieben und Schritte zur Reproduktion angegeben. Was gehört sonst noch in einen Bugreport? Dokumentation! Durch Hinzufügen der folgenden Informationen (falls vorhanden) kann das Projektteam schnell Prioritäten setzen und der Entwickler kann gezielt die Ursachen zurückverfolgen:
- Fehlertext (und ggfs. Fehler-ID), falls ein Fehler ausgegeben wird,
- die Testumgebung, in der das Problem auftrat (ist das Problem in allen, nur einigen oder einer einzigen Testumgebung reproduzierbar?),
- Screenshots und/oder Videomaterial, auf denen die Schritte zu sehen sind, die zum Fehler führen,
- Protokolle (Geräte-, Crash-, Netzwerkprotokolle usw.), die bei Auftreten des Problems angelegt wurden und den Entwicklern bei der schnelleren Eingrenzung des Problems helfen können,
- wie oft das Problem reproduziert wurde (in einigen Fällen kann ein Problem zwar legitim sein, jedoch nur periodisch auftreten),
- zusätzliche Hinweise, die angeführt werden können.
Herzlichen Glückwunsch! Du hast soeben einen effektiven Bugreport geschrieben, anhand dessen das Projektteam und die Entwickler das Problem verstehen und identifizieren können, sodass sie ihm die angemessene Priorität zuweisen und es vor allem lösen können.
Wenn du noch konkretere Fragen zu diesem Thema hast,wende dich gerne an unser Team. Hier bei Applause editieren und prüfen unsere Team Leads jede Woche Tausende von Bugreports. Wir sind auf einfach verständliche Bugreports spezialisiert, die Entwicklern ein schnelles Handeln ermöglichen.
