Ein Fehlerbericht ist keine Beschwerde. Es handelt sich um eine Reihe von Anweisungen und Beweisen, mit denen jemand anderes ein Problem reproduzieren, seine Auswirkungen verstehen und entscheiden kann, was als nächstes zu tun ist. Wenn Fehlerberichte vage sind, verbrennen die Teams die Zeit bei Hin- und Her-Nachrichten, Vermutungen und Sackgassen, die nicht reproduziert werden können. Wenn sie gut geschrieben sind, bewegen sich die Korrekturen schneller, die Prioritäten sind klarer und alle bleiben ruhiger.
Dieser Leitfaden zeigt eine praktische, Entwickler-freundliche Möglichkeit, Fehler zu melden. Sie erhalten eine Struktur, die in jedem Ticketsystem funktioniert, Tipps zum Schreiben reproduzierbarer Schritte, eine Anleitung zum schnellen Schweregrad sowie kopierfertige Vorlagen und Beispiele.
Was ein Fehlerbericht erreichen soll
Ein nützlicher Fehlerbericht beantwortet drei Fragen:
- Kann ich es reproduzieren? (Schritte + Umgebung + Testdaten)
- Was genau ist falsch? (tatsächliches vs erwartetes Verhalten)
- Wie viel ist es wichtig? (Aufprall + Schweregrad + Frequenz)
Es hilft auch, das Problem richtig zu klassifizieren. Nicht alles ist ein „Bug“. Manchmal handelt es sich um eine Feature-Anfrage, eine Support-Frage oder ein Umgebungsproblem. Eine klare Berichterstattung hält Ihren Rückstand sauber und Ihre Engineering-Zeit konzentriert.
Bevor Sie schreiben: 5 Minuten Vorbereitung, die Stunden spart
Auf Duplikate prüfen
Durchsuchen Sie vorhandene Tickets mithilfe von Schlüsselwörtern wie Fehlermeldungen, Feature-Namen oder Bildschirmtiteln. Wenn ein ähnliches Problem besteht, fügen Sie Ihre Daten als Kommentar hinzu, anstatt ein neues Ticket zu erstellen.
Wieder reproduzieren und den genauen Fluss erfassen
Versuchen Sie, das Problem noch einmal zu reproduzieren und dokumentieren Sie die Schritte genau. Wenn das Problem intermittierend ist, schätzen Sie, wie oft es auftritt und unter welchen Bedingungen.
Sammeln Sie die Mindestnachweise
- Screenshots für UI- oder Layoutprobleme
- Kurze Videos für Timing- oder mehrstufige Probleme
- Protokolle oder Konsolenausgabe für Abstürze oder API-Fehler
- Desinfizierte Beispieldaten, wenn Daten das Problem auslösen
Die Anatomie eines starken Fehlerberichts
Titel
Ein guter Titel folgt der Formel: Was passiert + wo + unter welchen Bedingungen.
- Kasse: Die Schaltfläche „Zahlen“ bleibt nach dem Anwenden des Rabattcodes deaktiviert
- Dashboard-Berichte: CSV-Export schlägt für Datumsbereich über 90 Tage fehl
- Mobile Safari: Sticky Header überlappt Suchergebnisse nach dem Scrollen
Umwelt
- Anwendungsversion oder Build-Nummer
- Browser oder Gerät und Betriebssystemversion
- Benutzerrolle oder Berechtigungen
- Gebietsschema, Zeitzone oder Netzwerkbedingungen, falls relevant
Voraussetzungen
- Der Benutzer ist als Administrator angemeldet
- Das Konto hat ein aktives Abonnement
- Dataset enthält einen Datensatz mit leeren Feldern
Schritte zum Reproduzieren
- Melden Sie sich als Benutzer mit der Manager-Rolle an.
- Berichte öffnen → Umsatz.
- Wählen Sie Datumsbereich „Letzte 180 Tage“.
- Klicken Sie auf CSV exportieren.
Tatsächliches Ergebnis vs erwartetes Ergebnis
Das tatsächliche Ergebnis beschreibt, was tatsächlich passiert, einschließlich etwaiger Fehlermeldungen. Das erwartete Ergebnis beschreibt, was aus der Sicht des Benutzers geschehen soll.
Frequenz
- Immer
- Oft
- Manchmal
- Selten
Schwere und Wirkung
| Schwere | Bedeutung | Beispiel |
|---|---|---|
| Blocker | Stoppt den Kern-Workflow | Benutzer können sich nicht anmelden |
| Kritisch | Datenverlust oder Sicherheitsrisiko | Datensätze unerwartet gelöscht |
| Major | Schlüsselfunktion kaputt | Der Export schlägt ohne Problemumgehung fehl |
| Moll- | Ärgerlich, aber nicht blockierend | Problem mit der UI-Ausrichtung |
| Trivial | Kosmetisches Problem | Kleiner Tippfehler |
Beispiele
UI-Beispiel
Titel: Mobile Safari: Sticky Header überlappt die Suchergebnisse nach dem Scrollen
Umgebung: iPhone 13, iOS 17.3, Safari, App Build 2.8.1
Voraussetzungen: Als Standardbenutzer angemeldet
- Öffnen Sie die Suchseite.
- Geben Sie „Polymer“ ein und senden Sie es.
- Blättern Sie bis 20 Ergebnisse laden.
Tatsächliches Ergebnis: Der Header überlappt die ersten Ergebnisse.
Erwartetes Ergebnis: Ergebnisse sind vollständig sichtbar und anklickbar.
API-Beispiel
Titel: Reports API gibt 500 für Exporte über 90 Tage zurück
Umgebung: Produktion
Voraussetzungen: Das Konto enthält mehr als 10.000 Datensätze
- Eröffneter Umsatzbericht.
- Wählen Sie den Zeitraum von 180 Tagen aus.
- Klicken Sie auf CSV exportieren.
Tatsächliches Ergebnis: 500 interner Serverfehler.
Erwartetes Ergebnis: CSV-Downloads erfolgreich oder eine klare Warnung wird angezeigt.
Fehlerbericht-Vorlage
Title: Environment: Preconditions: Steps to reproduce: 1) 2) 3) Actual result: Expected result: Frequency: Impact: Severity: Workaround: Attachments / Evidence:
Endgültige Checkliste
- Schritte sind klar und minimal
- Das tatsächliche und erwartete Verhalten werden getrennt
- Umgebung und Kontext sind enthalten
- Beweise werden beigefügt und saniert
- Wirkung wird erklärt
Schlussfolgerung
Ein übersichtlicher Fehlerbericht spart allen Beteiligten Zeit. Es reduziert Verwirrung, beschleunigt Korrekturen und verbessert die Zusammenarbeit zwischen Benutzern, Qualitätssicherung und Entwicklern. Konsistente Struktur und Klarheit sind wichtiger als die Länge oder der Fachjargon.