Ein Fehlerbericht ist Kommunikationsmittel und Dokumentation eines Defekts zugleich. Ein guter Bericht spart Zeit: Entwickler können das Problem reproduzieren, Verantwortliche verstehen seine Auswirkungen und QA kann die Korrektur sowie zugehörige Risiken verfolgen.
Was ein Bericht üblicherweise enthält
- →Einen klaren Titel, der das Problem benennt.
- →Umgebung und relevante Vorbedingungen.
- →Schritte zur Reproduktion.
- →Tatsächliche und erwartete Ergebnisse.
- →Nachweise: Screenshots, Videos, Protokolle, Netzwerkmitschnitte, Nutzlasten oder Stack-Traces.
Was einen guten Bericht ausmacht
- →Das Problem ist leicht verständlich und reproduzierbar.
- →Fakten werden von Interpretationen getrennt.
- →Die Auswirkungen auf Benutzer, Geschäft oder System werden erklärt.
- →Unwichtige Details erschweren Entscheidungen nicht.
Häufige Fehler
- →Ein vager Titel wie „Schaltfläche funktioniert nicht“.
- →Fehlende oder zu abstrakte erwartete Ergebnisse.
- →Schritte, die wesentliche Bedingungen auslassen und den Fehler nicht reproduzieren.
- →Priorität und Schweregrad nach Gefühl statt nach Risiko festlegen.
Praktische Hinweise
Für jemanden schreiben, der den Testkontext nicht kennt. Je schneller diese Person erkennt, was fehlgeschlagen ist, wie es reproduziert wird und warum es wichtig ist, desto besser ist der Bericht.
Ausgearbeitetes Beispiel: ein reproduzierbarer Fehlerbericht
Das folgende Beispiel ist fiktiv und dient der Schulung; es beschreibt keinen in einem echten Produkt beobachteten Fehler. Angenommen, REG-04 erlaubt für einen Spitznamen 3–12 ASCII-Buchstaben einschließlich beider Grenzen. Der Beispiel-Build lehnt genau 3 Buchstaben fälschlicherweise ab. Echte Berichte immer an eine freigegebene Anforderung und eine tatsächliche Beobachtung knüpfen.
ID: DEMO-17
Titel: Registrierung lehnt einen nach REG-04 zulässigen Spitznamen mit 3 Buchstaben ab
Umgebung: fiktiver Schulungs-Build 1.0; Browser und Betriebssystem: tatsächliche Versionen erfassen
Vorbedingungen: Registrierungsformular geöffnet; alle anderen Felder enthalten gültige Daten
Schritte:
1. abc in das Feld Spitzname eingeben.
2. Den Fokus zum nächsten Feld bewegen.
3. Das Formular absenden.
Erwartet: kein Fehler zur Länge des Spitznamens; die Registrierung kann fortgesetzt werden.
Tatsächlich in diesem fiktiven Szenario: "Minimum 4 characters"; das Absenden wird blockiert.
Reproduzierbarkeit: 3 von 3 Versuchen nach dem Zurücksetzen des Formulars.
Auswirkung: Ein zulässiger Spitzname kann nicht registriert werden.
Zu erfassende Nachweise: Screenshot, Build-ID, Zeitstempel und Anfrage/Antwort ohne sensible Daten.
Anforderung: REG-04.
Schweregrad / Priorität: anhand der Teamdefinitionen und des Release-Kontexts abstimmen.Der Titel nennt Aktion, Eingabe und Abweichung. Er vermutet nicht, dass das Backend verantwortlich ist. Wurde nur die UI beobachtet, diese Tatsache festhalten; vor der Behauptung einer serverseitigen Ursache die Anfrage untersuchen. Die oben genannten Screenshots und Protokolle sind zu sammelnde Nachweise, keine Anhänge dieser Anleitung.
Kopierbare Berichtsvorlage
Titel:
Build / Umgebung:
Anforderung oder Quelle des erwarteten Verhaltens:
Vorbedingungen und Testdaten:
Schritte:
Erwartetes Ergebnis:
Tatsächliches Ergebnis:
Reproduzierbarkeit:
Auswirkung auf Benutzer:
Nachweise ohne sensible Daten:
Verknüpfter Fehler / Testfall:Vor dem Absenden ein Teammitglied bitten, ausschließlich die dokumentierten Schritte auszuführen. Zugangsdaten und personenbezogene Daten aus den Nachweisen entfernen. Ein noch nicht reproduzierbarer Bericht kann trotzdem nützlich sein: Bekanntes, Häufigkeit und fehlende Informationen nennen.