Zu wissen, wie man einen effektiven Bug-Report erstellt, ist ein wichtiger Teil der Arbeit eines Softwaretesters, um die Qualitätssicherung aufrechtzuerhalten. Daher verbringen wir viel Zeit damit, Fehler in unseren Bug-Tracking-Tools zu dokumentieren. Einen Fehler zu finden, kann spannend sein – besonders, wenn es sich um ein interessantes Szenario handelt. Doch wie wir ihn melden, kann genauso wichtig sein wie seine Auswirkung auf das System.
Ein schlecht formulierter Bug-Report kann viel Reibung zwischen Teammitgliedern verursachen, insbesondere zwischen Testern und Entwicklern. Das kann die Fehlerbehebung blockieren und letztendlich das Nutzererlebnis beeinträchtigen.
In diesem Artikel teile ich wichtige Details, zum Beispiel wie man:
- Bug-Reports meistern: Erfahren Sie, welche Schlüsselelemente jeder effektive Bug-Report enthalten sollte, um die Kommunikation zu vereinfachen und Fehler schneller zu beheben.
- Team-Harmonie fördern: Entdecken Sie, wie gut geschriebene Bug-Reports Reibung zwischen Testern und Entwicklern verhindern und so reibungslosere Arbeitsabläufe ermöglichen.
- Kostenlose Download-Vorlage: Erhalten Sie eine kostenlose, herunterladbare Vorlage zur Fehlerverfolgung, um Ihren effizienten Bug-Reporting-Prozess sofort zu starten.
Wichtige Elemente eines Bug-Reports
Unabhängig davon, welche Art von Anwendung Sie testen – ob Desktop-, Web-, Mobile-App oder ein API-Projekt – gibt es einige Schlüsselaspekte, die jeder gute Bug-Report enthalten sollte. Die meisten Bug-Tracking-Programme bieten Felder für diese Elemente an, zum Beispiel:
- ID: Wenn Sie ein Projektmanagement-Tool wie Jira verwenden, wird jeder neuen Fehlermeldung automatisch eine ID zugewiesen. Es gibt auch Testmanagement-Tools für Jira zur Fehlerverfolgung.
- Titel/Beschreibung: Dies ist eine kurze Beschreibung des Problems. Sie sollte knapp genug sein, um leicht zu lesen, aber dennoch so präzise, dass andere verstehen, wo das Problem liegt. Zum Beispiel: „Sortierung der Artikel nach Preis funktioniert nicht, wenn ein Filter angewendet ist.”
- Schritte zur Reproduktion: Geben Sie hier so viele relevante Details wie möglich an. Stellen Sie sicher, dass jeder, der den Fehler reproduzieren oder die Korrektur überprüfen möchte, dies durch Befolgen der Schritte tun kann. Überspringen Sie keine Schritte, weil Sie annehmen, dass jeder weiß, was zu tun ist, auch wenn es nicht erwähnt ist; führen Sie alle Schritte im Bug-Report aus.
- Erwartetes Ergebnis: Nehmen Sie auch hier nicht an, dass andere schon wissen, wie die Anwendung sich verhalten soll. Wenn Sie beispielsweise beim Drücken eines Buttons eine Ausnahme im UI erhalten, wissen Sie, dass das nicht erwartet ist. Dennoch sollte das erwartete Ergebnis nicht „es wird keine Ausnahme ausgelöst” sein, sondern was der Button eigentlich machen sollte, z.B. „Der Einstellungsdialog wird geöffnet.”
- Tatsächliches Ergebnis: Dies erklärt sich von selbst – Sie sollten beschreiben, was in der Anwendung geschieht, nachdem alle Reproduktionsschritte durchgeführt wurden.
- Schweregrad: Dies gibt an, wie stark sich der Fehler auf das zu testende System (AUT) auswirkt.
- Priorität: Wie schnell der Fehler behoben werden sollte. Eine höhere Priorität bedeutet, dass der Fehler weiter oben im Backlog platziert und früher behoben werden sollte.
Weitere wichtige Informationen, die Sie einbeziehen sollten
Neben den oben genannten Elementen können weitere Angaben wichtig sein, insbesondere beim Eintragen von Daten in ein Bug-Reporting-Tool. Diese können vom Projekttyp, den Projektanforderungen oder auch von der Art des Fehlers abhängen:
- Software-Version: Die Build-Nummer, in der der Fehler entdeckt wurde. Das erleichtert es, Builds zu isolieren, in denen das Problem möglicherweise erstmals auftrat, und den verursachenden Codeabschnitt zu lokalisieren.
- Anhänge: Diese sind zwar nicht immer notwendig oder verfügbar, bieten jedoch meistens einen großen Mehrwert. Stellen Sie zum Beispiel Screenshots, Bildschirmaufnahmen, Logdateien, Stacktraces, Netzwerk-Anfragen und -Antworten usw. bereit, sofern möglich.
- Testdaten: Manchmal treten Fehler nur mit bestimmten Datensätzen auf. Falls dies der Fall ist, geben Sie diese an – entweder in den Reproduktionsschritten (zum Beispiel: „anmelden als Nutzer [email protected]“) oder in einem speziellen Feld des Bugtrackers.
- Umgebungsdetails: Wenn der Fehler nur in einem bestimmten Betriebssystem, Browser oder einer Entwicklungsumgebung auftritt, sollten Sie dies ebenfalls erwähnen.
Tipps für die Erstellung eines guten Bug-Reports
- Beschränken Sie sich auf einen einzigen Fehler pro Bericht. Wenn Sie weitere Fehler im selben Bereich entdecken, können Sie diese in Ihrem Issue Tracker verknüpfen. Das Hinzufügen von mehr als einem Defekt kann zu Verwirrung und Verzögerungen bei der Fehlerbehebung führen.
- Prüfen Sie in Ihrem Tracking-System, ob der Fehler bereits gemeldet wurde. Falls er bereits offen ist, fügen Sie alle relevanten Details hinzu, die im ursprünglichen Fehlerbericht nicht enthalten waren.
- Versuchen Sie, den Fehler mehrmals zu reproduzieren. Versuchen Sie, den kürzesten Weg zur Reproduktion zu finden (mit möglichst wenigen Schritten).
- Verlieren Sie sich nicht in irrelevanten Details. Der Fehlerbericht und die Schritte sollten leicht verständlich und nachvollziehbar sein.
- Stellen Sie keine Annahmen darüber an, warum der Fehler auftritt (es sei denn, Sie sind sich zu 100 % sicher, was ihn verursacht hat).
Fehlerbericht-Vorlage
Jetzt möchte ich Ihnen einige Vorlagen für Fehlerberichte vorstellen. Sie können diese je nach Bedarf Ihres Projekts kopieren oder anpassen.
Jira Fehlerverfolgungs-Vorlage
Jira ist ein sehr verbreitetes Tool zur Fehlerverfolgung von Atlassian. Wenn Ihr Team es verwendet, ist der Fehlertyp wahrscheinlich bereits konfiguriert. Als Tester oder Manager eines Softwareentwicklungsteams können Sie einen Workflow für die Fehlerverfolgung für den Lebenszyklus von Bugs einrichten.
Sie können in Jira auch benutzerdefinierte Felder hinzufügen, z. B. für die Umgebung oder ein eindeutiges Feld, in dem die getestete Funktionalität eingetragen wird. Oder Sie fügen eine Standardbeschreibung mit allen Informationen hinzu, die jeder Fehlerbericht enthalten soll. Hier ist eine, die ich erstellt habe:

Wenn ich nun einen neuen Fehler erfassen möchte, habe ich diese Angaben bereits vorausgefüllt. Hier ist meine Fehlerbericht-Vorlage in Jira mit benutzerdefinierten Feldern und einer Standardbeschreibung:

Sie enthält die wichtigen Informationen, die im Fehlerbericht nicht fehlen dürfen:
- Ein Titel („Beispielfehler“)
- In der Beschreibung: die Voraussetzungen, die Reproduktionsschritte und die erwarteten vs. die tatsächlichen Ergebnisse
- Ein benutzerdefiniertes Feld für die Umgebung
- Eine Schwere und eine Priorität, jeweils auswählbar aus Drop-down-Menüs mit vordefinierten Werten
- Ich habe die/den Bearbeiter/in freigelassen. Je nach Konvention im Projekt können neue Fehler automatisch einer bestimmten Person zugewiesen werden, oder die Person, die daran arbeitet, weist den Fehler sich selbst zu
- Ein Label – das kann z. B. hilfreich sein, um zu verfolgen, welche Funktionalität betroffen ist
- Ein Fälligkeitsdatum – dieses kann eventuell erst gesetzt werden, wenn das Backlog priorisiert wurde
- Der/die Berichtende (dies wird in diesem Fall automatisch vom Jira-Benutzer, der den Fehler erstellt hat, übernommen)
Optional verfügt Jira über zahlreiche Integrationen, sodass der Fehler mit Testfällen, Git-Branches oder sogar Pull Requests verknüpft werden kann.
Sie können auch die Fehlerverfolgungs-Vorlage als Projektvorlage nutzen, wenn Sie Jira nur für die Defektverfolgung brauchen und nicht in einer agilen Umgebung arbeiten.
Excel Fehlerverfolgungs-Vorlage
Manche Teams nutzen für ihr Fehlermanagement Tabellen. Ich finde diese für sehr kleine Projekte sinnvoll, bei denen es sich nicht lohnt, ein eigenes Fehlerverfolgungssystem einzurichten, oder um Fehler bei neuen Funktionen zu melden, die sich noch in Entwicklung befinden.
Sie können Google Sheets/Docs oder Microsoft Excel/Word verwenden – so oder so kann eine Fehlerbericht-Vorlage so aussehen:

Die Spalten spiegeln die Informationen wider, die der Bericht enthalten sollte:
- Die ID (Excel weiß, wie der Wert bei jeder neuen Zeile automatisch erhöht wird)
- Ein Titel
- Die Schritte zur Reproduktion
- Erwartetes und tatsächliches Ergebnis
- Name des Meldenden
- Schweregrad und Bug-Priorität – hier habe ich Dropdowns verwendet, da die Werte vordefiniert sein sollten
- Umgebung
- Zusätzliche Informationen: Dies ist für alles Weitere, was erwähnenswert ist und nicht in die anderen Spalten passt
Abschließende Gedanken
Das Verfassen eines guten Software-Bug-Reports ist eine wichtige Fähigkeit für Softwaretester. Achten Sie daher besonders auf die oben erläuterten Best Practices. Sie können sich auch auf die von mir bereitgestellten Bugtracker-Vorlagen stützen. Diese lassen sich an die verschiedenen von Ihnen verwendeten Tools wie Trello oder Asana anpassen.
Wenn Ihnen dieser Inhalt gefallen hat, abonnieren Sie den Newsletter The QA Lead, um weiterhin über Neuigkeiten und Trends im Software-Testprozess informiert zu bleiben!
