Auf einen guten Fehlerbericht folgt ein Fix. Ein schlechter bekommt das Label „nicht reproduzierbar“, eine Rückfrage, auf die niemand mehr antwortet, und einen langsamen Tod ganz unten im Backlog. Der Unterschied liegt selten am Aufwand. Es kommt darauf an, ob du weißt, was die Person braucht, die den Bug behebt.
Hier geht es um den Aufbau eines Berichts, der die Triage übersteht: für Berichte, die du selbst schreibst, und für den Fall, dass du Nutzenden und deinem Team beibringen willst, bessere zu schreiben.
Woraus ein brauchbarer Bericht besteht
Ein Titel, der den Fehler beschreibt, nicht das Gefühl
„Checkout ist kaputt“ sagt niemandem im Entwicklungsteam etwas. „Checkout: Nach Eingabe eines Rabattcodes zeigt der Klick auf Bezahlen endlos einen Spinner“ sagt, wo man suchen und was man ausprobieren muss, und deutet den Auslöser an. Ein guter Titel nennt den Ort, die Aktion und das beobachtete Ergebnis.
Schritte zur Reproduktion
Schreib die kürzeste Abfolge auf, die den Bug auslöst, und beginne bei einem bekannten Zustand:
Mit einem Kundenkonto einloggen, ein Artikel liegt im Warenkorb
Rabattcode SAVE10 eingeben
Auf Bezahlen klicken
Nummerierte Schritte sind wichtig, weil die Person, die den Bug behebt, ihnen wörtlich folgt. Ist Schritt 2 entscheidend und du lässt ihn weg, tritt der Bug bei dir auf und bei ihr nicht. Dann steckt ihr beide fest.
Erwartetes und tatsächliches Verhalten
Zwei kurze Zeilen: was hätte passieren sollen und was stattdessen passiert ist. Das klingt nach Bürokratie, bis du auf einen Bug stößt, bei dem ihr euch nicht einmal einig seid, was „richtig“ überhaupt ist. „Erwartet: Seite mit der Bestellbestätigung. Tatsächlich: endloser Spinner, nach dem Klick keine Netzwerkaktivität“ räumt jede Unklarheit aus.
Die Umgebung
Browser und Version, Betriebssystem, Gerät, Bildschirmgröße und die genaue URL der Seite. Erstaunlich viele Frontend-Bugs hängen von der Umgebung ab: ein Fehler beim Parsen von Datumswerten nur in Safari, ein Layout, das nur bei Tablet-Breite kaputtgeht. Ohne Angaben zur Umgebung testet das Entwicklungsteam im eigenen Browser, sieht nichts und schließt den Bericht.
Die Belege
Hier entscheidet sich, ob die Diagnose fünf Minuten dauert oder einen Tag:
Console-Ausgabe: die tatsächliche Fehlermeldung mit Stacktrace, nicht nacherzählt.
Netzwerkaktivität: welcher Request fehlgeschlagen ist und mit welchem Statuscode.
Ein Screenshot oder eine Aufnahme: vor allem bei visuellen und Layout-Bugs, bei denen tausend Worte wirklich schlechter sind als ein Bild.
Zeitpunkt: wann es passiert ist, damit man es mit Server-Logs und Deploys abgleichen kann.
Warum Nutzende nichts davon tun
Der unangenehme Teil: Diese Checkliste kann man vom QA-Team verlangen, von Nutzenden wäre sie absurd. Sie wissen nicht, was eine Console ist, schlagen ihre Browserversion nicht nach und schreiben keine Schritte zur Reproduktion auf. Mehr als „funktioniert nicht“ ist beim besten Willen nicht drin, und jedes zusätzliche Feld im Fehlerformular kostet dich weitere Berichte.
Du hast zwei Möglichkeiten. Entweder du nimmst vage Berichte hin und zahlst den Preis bei der Triage. Oder du sammelst die technische Hälfte des Berichts automatisch und lässt die Person das beitragen, was nur sie weiß: was sie gerade versucht hat.
Auf diesem Modell beruhen Widgets für Fehlerberichte. Mit einem Tool wie BugDump klickt die Person auf einen Button und tippt einen Satz. Console-Logs, Netzwerk-Requests, Session-Replay, Angaben zur Umgebung und die URL der Seite hängt das Widget selbst an. Steht im Bericht nur „auf Bezahlen geklickt, nichts passiert“, reicht das, denn die nicht abgefangene Exception und der fehlgeschlagene Request liegen direkt daneben.
Die Checkliste
Für Berichte, die ein Mensch komplett selbst schreibt (interne QA, Berichte aus dem Team, GitHub-Issues):
Der Titel nennt Ort + Aktion + beobachtetes Ergebnis
Nummerierte Schritte zur Reproduktion, ab einem bekannten Ausgangszustand
Erwartetes Verhalten in einer Zeile
Tatsächliches Verhalten in einer Zeile
Umgebung: Browser + Version, Betriebssystem, Gerät, Viewport, URL
Console-Fehler, wörtlich kopiert
Fehlgeschlagener Netzwerk-Request mit Statuscode, falls vorhanden
Screenshot oder Aufnahme bei allem Visuellen
Schweregrad und Auswirkung: Wen trifft es und wie oft?
Bei Berichten von Nutzenden sieht die Checkliste anders aus. Die meisten Häkchen sollte dort ein Tool setzen, nicht ein Mensch:
Beschreibung in den eigenen Worten der Person (das einzige Pflichtfeld)
Alles andere (Umgebung, Console, Netzwerk, Replay) automatisch erfasst
Bei eingeloggten Personen automatisch angehängt, wer gemeldet hat, damit Rückfragen möglich sind
Ein Bericht, ein Bug
Widersteh der Versuchung, alles zu bündeln. „Das Dashboard ist langsam, außerdem ist der Export-Button kaputt und der Dark Mode sieht falsch aus“ sind drei Bugs, die sich eine Berichts-ID teilen. Gebündelte Berichte lassen sich nicht priorisieren (die Schweregrade unterscheiden sich), nicht schließen (nach einem Fix ist der Bericht noch zu zwei Dritteln offen) und nicht sauber zuweisen. Schreib drei Berichte. Wenn dein Bug-Tracker Berichte Aufgaben zuordnet, zahlt sich die Disziplin sofort aus: BugDump macht aus Berichten Karten auf einem Kanban-Board, und jede Karte wandert für sich.
Ehrlicher Schweregrad
Bewerte den Schweregrad nach der Auswirkung, nicht nach deinem Ärger. Ein Tippfehler, der dir persönlich peinlich ist, hat einen niedrigen Schweregrad. Ein fehlschlagender Bezahlvorgang in einem einzigen Browser hat einen hohen, auch wenn du ihn nicht reproduzieren kannst. Sind Berichte immer als „kritisch“ markiert, lernt das Team, das Feld komplett zu ignorieren, und das ist schlimmer, als es gar nicht zu haben.
Was es bringt
Gute Fehlerberichte zahlen sich mit Zinseszins aus. Jeder mit echten Belegen wird schneller behoben. Das hält das Backlog kurz, das hält die Triage schnell, und so bleibt mehr Zeit für die Berichte, die wirklich schwierig sind. Und die Gewohnheit steckt an: Wer gute Berichte bekommt, fängt an, selbst welche zu schreiben.
Schreib den Bericht, den du selbst freitags um 17 Uhr bekommen möchtest, und automatisiere alles, wofür die meldende Person kein Fachwissen brauchen sollte.
Die Vorlage für Fehlerberichte, die funktioniert (und wie du sie überflüssig machst) – eine Vorlage, die bleiben darf, und warum drei Viertel ihrer Felder der Browser ausfüllen kann.
Anatomie eines Fehlerberichts: was BugDump erfasst und warum – jedes Signal, das das Widget sammelt, und welche davon wirklich Bugs lösen.
Was tun mit einem Fehlerbericht, den du nicht reproduzieren kannst – die üblichen Ursachen, der Kontext, der sie aufklärt, und wie du verhinderst, dass sie wiederkommen.