Einen brauchbaren Fehlerbericht schreiben

Ziel

Der Bericht enthält alles, was die empfangende Seite – Entwicklerin, Betreiber oder Agent – braucht, um den Fehler beim ersten Versuch nachzustellen und einzuordnen, und nichts, was sie erst wegräumen muss.

Voraussetzungen

Der Fehler wurde mindestens einmal selbst beobachtet; die Umgebung ist bekannt (Version, Betriebssystem, Browser oder Laufzeit, Einstellungen, die vom Standard abweichen).

Schritte

1. Vorher suchen: Gibt es den Bericht schon? Dann dort ergänzen statt einen zweiten eröffnen.
2. Überschrift als Satz mit Symptom und Bedingung: «Export bricht bei Dateinamen mit Umlaut mit UnicodeEncodeError ab», nicht «Export kaputt».
3. Umgebung angeben: Produktversion oder Commit, Betriebssystem, Laufzeit oder Browser mit Version, relevante Einstellungen. Was vom Standard abweicht, gehört hierhin.
4. Schritte zum Nachstellen als nummerierte Liste, jede mit genau einer Handlung, beginnend bei einem bekannten Ausgangszustand (frische Installation, Beispieldatei im Anhang). Die Mozilla-Leitlinie (zitiert) verlangt genau diese Trennung von «Steps to Reproduce», «Expected Results» und «Actual Results».
5. Erwartetes und tatsächliches Ergebnis in je einem Satz; die Fehlermeldung wörtlich und vollständig (Stack-Trace als Codeblock, nicht als Bildschirmfoto), Protokollauszug mit Zeitstempel.
6. Verkleinern, soweit die Zeit reicht: Schritte und Daten entfernen, bis der Fehler verschwindet, und die letzte Entfernung zurücknehmen. Das Stack-Overflow-Muster «minimal, complete, reproducible» ist der Massstab; manchmal wird die Ursache schon beim Verkleinern sichtbar.
7. Häufigkeit und Auswirkung: immer oder gelegentlich, seit wann, wie viele Betroffene, ob es eine Umgehung gibt.
8. Vermutungen zur Ursache in einen eigenen Abschnitt «Vermutung», klar getrennt von den Beobachtungen. Keine Bewertungen, keine Vorwürfe.
9. Vor dem Absenden lesen, als kenne man das Projekt nicht: Fehlt eine Datei, ein Befehl, eine Version?

Erwartetes Ergebnis

Der Empfänger stellt den Fehler nach, ohne zu fragen, und kann ihn priorisieren; der Bericht wird später zum Regressionstest, weil Schritte und Erwartung schon formuliert sind.

Grenzen und Prüfbasis

Manche Fehler lassen sich nicht deterministisch nachstellen (Zeitverhalten, Last, Nebenläufigkeit); dann gehören Häufigkeit, Zeitpunkte und die Bedingungen der Beobachtung in den Bericht. Vertrauliche Daten in Anhängen und Protokollen sind vorher zu entfernen. Der Aufbau folgt den zitierten Leitlinien; Aussagen über Bearbeitungszeiten werden nicht gemacht.