Bug-Report schreiben: eine Vorlage, die Fehler reproduzierbar macht

Ein Fehler ist erst dann gut beschrieben, wenn andere ihn verstehen

„Die Seite funktioniert nicht“ hilft einem Team kaum weiter. Vielleicht ist ein Button nicht sichtbar, vielleicht geht ein Formularinhalt verloren oder eine Meldung erscheint nur bei einem bestimmten Browser. Ein guter Bug-Report macht die Beobachtung so konkret, dass jemand sie möglichst unter vergleichbaren Bedingungen wiederholen kann. Dafür brauchst du kein Entwicklerwissen, sondern eine klare Reihenfolge.

Unterscheide zwischen Fehler, Verbesserungsidee und Frage. Wenn eine Schaltfläche gar nicht reagiert, ist das ein möglicher Fehler. Wenn du die Beschriftung unklar findest, ist es zunächst ein Usability-Befund. Wenn du nicht weißt, ob ein Schritt erlaubt ist, kläre ihn vor dem Test – insbesondere bei Finanz- und Verifizierungsabläufen.

Die Vorlage zum Kopieren

Du kannst folgende Struktur für einen Testbericht übernehmen und auf die konkrete Aufgabe kürzen:

Titel: Was tritt wo auf?
Umgebung: Gerät, Betriebssystem, Browser oder App-Version
Ausgangszustand: Wo beginnt der Test, welche fiktiven Testdaten sind freigegeben?
Schritte: 1. … 2. … 3. …
Erwartet: Was sollte nach dem letzten Schritt passieren?
Tatsächlich: Was ist stattdessen passiert?
Häufigkeit: Bei jedem Versuch oder nur gelegentlich?
Auswirkung: Ist die Aufgabe blockiert, erschwert oder nur irritierend?
Beleg: Geschwärzter Screenshot oder kurze Bildschirmaufnahme, falls erlaubt.

Beschreibe Schritte so, dass jemand sie ausführen kann. „Zum Tarif zurück, Filter aktivieren, Detailansicht öffnen, Zurück drücken“ ist verständlicher als „mehrmals geklickt“. Nummerierte Schritte helfen, wenn ein Problem nur in einer bestimmten Reihenfolge auftritt.

Beispiel: ein Filter vergisst die Auswahl

Titel: Im mobilen Tarifvergleich verschwindet der aktive Filter nach „Zurück“.
Umgebung: Android-Smartphone, Chrome, 390 px Ansichtsbreite; freigegebener Testzugang.
Schritte: 1. Tarifvergleich öffnen. 2. „Monatlich kündbar“ auswählen. 3. Einen Tarif öffnen. 4. Browser-Zurück verwenden.
Erwartet: Die Tarifliste zeigt weiterhin den gewählten Filter.
Tatsächlich: Die Liste enthält wieder alle Tarife, der Filter ist deaktiviert.
Häufigkeit: In zwei von zwei Versuchen.
Auswirkung: Der Vergleich muss erneut eingegrenzt werden.

Dieses Beispiel behauptet nicht, dass eine bestimmte reale Website den Fehler hat. Es zeigt nur, wie eine konkrete Beobachtung beschrieben werden kann. Für App-Tests und Website-Usability-Tests gilt das gleiche Grundmuster.

Was bei Screenshots oft schiefgeht

Ein Screenshot ohne Kontext zeigt zwar die Oberfläche, aber nicht unbedingt den Weg dorthin. Ergänze deshalb Zeitpunkt oder Schrittzahl und markiere die betreffende Stelle sachlich. Schneide irrelevante Teile weg. Schwärze private Namen, Adressen, Kontodaten, Ausweisbilder und Zugangsdaten vollständig; ein halbtransparentes Rechteck ist keine zuverlässige Schwärzung.

Vermeide Fotos, auf denen Bildschirmspiegelungen oder Benachrichtigungen sensible Inhalte preisgeben. Für einen Test reicht meist ein künstlich erzeugter Datensatz. Wenn eine Aufnahme nicht freigegeben ist, beschreibe den Fehler in Worten und frage nach der erlaubten Nachweisform.

Schweregrad und Ursache getrennt bewerten

Ein Problem kann häufig, aber wenig störend sein. Ein anderes tritt nur selten auf, blockiert dann aber den gesamten Ablauf. Notiere die Auswirkung: Blockiert, erschwert oder irritiert die Aufgabe? Vermeide spekulative Aussagen wie „das Backend ist kaputt“, wenn du nur die sichtbare Wirkung kennst. Teams können die technische Ursache später selbst prüfen.

Hilfreich sind auch Gegenbeispiele: „Auf dem Desktop funktioniert derselbe Schritt“ oder „Nach einem frischen Start tritt der Fehler nicht auf“. Solche Hinweise erleichtern die Eingrenzung. Bei Fehlern, die du nicht reproduzieren kannst, schreibe genau das und bewahre den Kontext auf, statt eine Sicherheit vorzutäuschen.

Zum Schluss: eine kurze Kontrollfrage

Könnte jemand, der nicht dabei war, anhand deines Berichts die Aufgabe nachstellen und die Auswirkung verstehen? Wenn ja, ist dein Bericht bereit. Wenn nein, ergänze zuerst Ausgangszustand, Schritte und erwartetes Ergebnis. Die Checkliste für App-Tests hilft dir, beim nächsten Durchlauf von Anfang an die nötigen Informationen mitzuschreiben.

Mehr über den Ablauf eines Auftrags steht auf So funktioniert Pruviso. Unternehmen erfahren unter digitale Praxistests, wie solche Beobachtungen in ein Projekt einfließen.

Weiterführende Grundlage

• W3C WAI: Evaluation von Websites – ein Überblick über Methoden und die Grenzen einzelner Werkzeuge.

Vor dem Absenden: vier Fragen an den eigenen Bericht

Ist der Ausgangspunkt eindeutig? Eine eingeloggte und eine ausgeloggte Person können denselben Link unterschiedlich sehen. Schreibe deshalb auf, ob du einen neuen Testzugang, einen gespeicherten Entwurf oder einen bestimmten Browserzustand verwendet hast.

Sind die Schritte klein genug? Wenn zwischen zwei Nummern mehrere Entscheidungen liegen, kann das Team den Fehler möglicherweise nicht exakt reproduzieren. Teile den Weg lieber in kurze, beobachtbare Aktionen und markiere den Schritt, an dem das Verhalten erstmals abweicht.

Ist „erwartet“ begründet? Das erwartete Verhalten sollte aus dem Briefing, einer Beschriftung oder einem vorherigen konsistenten Verhalten hervorgehen. Wenn es nur deine persönliche Präferenz ist, nenne es als Verbesserungsidee. So wird aus einer Geschmacksfrage kein vermeintlicher technischer Defekt.

Sind Belege datensparsam? Ein Screenshot sollte die Stelle zeigen, die für den Befund erforderlich ist. Prüfe Bildränder, Browser-Benachrichtigungen, Chatfenster, Namen und E-Mail-Adressen. Nutze bei Formularen ausschließlich freigegebene fiktive Daten und entferne sensible Werte dauerhaft, bevor die Datei geteilt wird.

Wie ein Team den Befund weiterverarbeitet

Nach Eingang prüft das Team zuerst, ob der Bericht nachvollziehbar ist. Dann wird der Befund bestätigt, ergänzt oder als nicht reproduzierbar markiert. Eine Rückfrage ist kein Zeichen, dass die Beobachtung unwichtig war; häufig fehlt nur eine Umgebungsangabe. Wenn mehrere Berichte denselben Ablauf betreffen, werden sie zu einem Problem gebündelt. Das verhindert, dass eine einzelne Ursache mehrfach gezählt wird.

Eine Priorität sollte sich an der Auswirkung orientieren, nicht an der Lautstärke der Formulierung. Ein ruhiger Bericht über einen Blocker ist wichtiger als ein dramatischer Text über ein kleines Icon. Hilfreich sind Angaben wie „Aufgabe nach diesem Schritt nicht möglich“, „mit Umweg lösbar“ oder „nur missverständlich, aber abschließbar“. Die endgültige technische Ursache ermittelt das Produktteam; die Testperson liefert die reproduzierbare Beobachtung.

Positive Befunde gehören ebenfalls hinein

Ein Bericht wird ausgewogener, wenn er funktionierende Teile benennt. „Die Fehlermeldung nennt das betroffene Feld und der bereits eingegebene Text bleibt erhalten“ zeigt, welche Lösung bereits trägt. Positive Beobachtungen helfen Teams, gute Muster auf andere Schritte zu übertragen. Sie machen den Bericht außerdem verständlicher, weil klar wird, woran das erwartete Verhalten gemessen wurde.

Für mobile Anwendungen kannst du zusätzlich die Anleitung zum systematischen App-Test verwenden. Bei Formularen und responsiven Oberflächen ergänzt die Website-Usability-Anleitung den Bericht um Fragen zu Aufgabe, Zielgruppe und Priorisierung.