Ein Fehlerbericht (Bug Report) dokumentiert, wann und wo eine Fehlerwirkung aufgetreten ist, worin sie besteht und in welchem Status sie sich befindet, damit Entwicklung und Test sie nachstellen und beheben können. Der ISTQB-Lehrplan CTFL 4.0 (deutsche Fassung 4.0.2) nennt dafür elf typische Inhalte, von der eindeutigen Kennung bis zu den Referenzen.

Die elf Felder stehen unten als kopierbare Vorlage, dazu ein ausgefülltes Beispiel aus dem Zahlungsverkehr und die Regeln aus Mozillas Bug-Writing-Guidelines. Der Bericht ist der erste Schritt im Fehlermanagement im Softwaretest. Jede Angabe, die hier fehlt, kommt später als Rückfrage zurück.

Kurz gefasst: Ein Fehlerbericht dokumentiert laut ISTQB-Glossar Auftreten, Art und Status eines Fehlerzustands. Der CTFL-Lehrplan nennt elf typische Felder, darunter Testumgebung, Testschritte, erwartetes und tatsächliches Ergebnis, Fehlerschweregrad und Priorität. Mozilla nennt die Schritte zur Reproduktion den wichtigsten Teil jedes Berichts. Ein Bericht beschreibt genau ein Problem.

Abbildung 1: Die 11 typischen Felder eines Fehlerberichts nach ISTQB

Was ist ein Fehlerbericht?

Ein Fehlerbericht ist ein Dokument im Fehlermanagement, das eine beobachtete Anomalie so festhält, dass andere sie nachstellen und bearbeiten können. Das offizielle ISTQB-Glossar definiert den defect report, Synonym bug report, als „Documentation of the occurrence, nature, and status of a defect“, auf Deutsch: Dokumentation von Auftreten, Art und Status eines Fehlerzustands (ISTQB-Glossar, 2026).

Der deutsche Lehrplan nennt drei Ziele eines Fehlerberichts (GTB, CTFL-Lehrplan 4.0.2, 2025):

• Die Verantwortlichen erhalten ausreichende Informationen, um das Problem zu beheben.

• Das Team kann damit die Qualität des Arbeitsergebnisses verfolgen.

• Der Bericht liefert Ideen zur Verbesserung des Entwicklungs- und Testprozesses.

Laut Lehrplan können sich gemeldete Anomalien als „falsch positives Ergebnis“ oder als „Änderungsanforderung“ herausstellen. Die Norm ISO/IEC/IEEE 29119-3 enthält Dokumentvorlagen und nennt Fehlerberichte „Abweichungsberichte“. Ihre Feldliste ist kostenpflichtig, die Vorlage unten folgt dem freien Lehrplan.

Welche Felder gehören in einen Fehlerbericht nach ISTQB?

Der CTFL-Lehrplan 4.0.2 nennt in Abschnitt 5.5 elf Inhalte, die „ein Fehlerbericht, der während des dynamischen Testens aufgezeichnet wird“, in der Regel enthält: Kennung, Titel, Datum und Autor, Testobjekt und Testumgebung, Kontext, Beschreibung der Fehlerwirkung, erwartetes und tatsächliches Ergebnis, Fehlerschweregrad, Priorität, Fehlerstatus und Referenzen (GTB, CTFL-Lehrplan 4.0.2, 2025). Die Tabelle macht daraus eine Vorlage zum Kopieren.

Kennung, Datum, Autor und den initialen Status können Fehlermanagement-Tools laut Lehrplan automatisch ergänzen. Tragen Sie in regulierten Umgebungen den Build so genau ein, dass ein Prüfer den getesteten Stand Monate später wiederfindet. Jeder Statuswert von „offen“ bis „zurückgewiesen“ hat im Fehlerlebenszyklus einen festen Platz.

Fehlerschweregrad und Priorität sind zwei getrennte Felder: Der eine beschreibt die Auswirkung, der andere die Reihenfolge der Behebung. Wie Teams Skalen dafür festlegen, zeigt der Vergleich Schweregrad und Priorität von Fehlern.

Wie sieht ein ausgefüllter Fehlerbericht aus?

Ein ausgefüllter Fehlerbericht nennt Umgebung, Reproduzierbarkeit, nummerierte Schritte, das erwartete und das tatsächliche Ergebnis. Beobachtungen hält er getrennt von Vermutungen, so wie es Mozillas Leitfaden verlangt (Mozilla Bug Writing Guidelines, abgerufen 2026). Das erfundene Beispiel unten zeigt das für ein Überweisungsformular im E-Banking einer Schweizer Bank.

ZV-1482: Inlandzahlung: 1’250.50 erscheint als 125’050.00

• Umgebung: TEST, E-Banking Web 4.12.0, Chrome auf Windows 11, Testkunde 7

• Reproduzierbarkeit: bei jedem Versuch (5 von 5)

• Fehlerschweregrad und Priorität: hoch, 1

• Referenzen: Testfall TF-ZV-031, Story ZV-210

Schritte zur Reproduktion

1. Als Testkunde 7 im E-Banking anmelden.

2. „Zahlungen“ und dann „Inlandzahlung“ öffnen.

3. Die Empfänger-IBAN aus Testdatensatz 3 einfügen.

4. Im Feld „Betrag“ den Wert 1’250.50 eintippen.

5. Auf „Weiter“ klicken und die Bestätigungsseite prüfen.

Erwartetes Ergebnis: Die Bestätigungsseite zeigt CHF 1’250.50, wie in Story ZV-210 festgelegt.

Tatsächliches Ergebnis: Die Bestätigungsseite zeigt CHF 125’050.00. Mit der Eingabe 1250.50 ohne Apostroph stimmt der Betrag.

Beobachtung: Der Fehler tritt nur bei Beträgen mit Tausender-Apostroph auf. Screenshot und Auszug aus der Browser-Konsole sind angehängt.

Vermutung (ungeprüft): Beim Speichern werden beide Trennzeichen entfernt.

Der Gegentest mit 1250.50 grenzt die Ursache ein, ohne eine Lösung vorzuschreiben. Die Vermutung ist als ungeprüft markiert, damit niemand sie für einen Befund hält.

Welche Regeln machen einen Fehlerbericht brauchbar?

Ein Fehlerbericht ist brauchbar, wenn ein Entwickler die Fehlerwirkung allein mit den angegebenen Schritten nachstellen kann. Mozillas Bug-Writing-Guidelines stellen genau diese Regel an den Anfang: „Steps to reproduce are the most important part of any bug report.“ Kann ein Entwickler den Fehler nachstellen, wird er laut Mozilla sehr wahrscheinlich behoben (Mozilla Bug Writing Guidelines, abgerufen 2026). Die übrigen Regeln derselben Seite taugen als Checkliste vor dem Absenden:

Abbildung 2: Was die Forschung zur Qualität von Fehlerberichten zeigt

• Ein Problem pro Bericht: „If you have multiple issues, please file separate bug reports.“

• Reproduzierbarkeit angeben: jederzeit, gelegentlich oder gar nicht.

• Fakten von Vermutungen trennen: Beobachtungen zuerst, Hypothesen sichtbar markiert.

• Früheste Version nennen, in der sich das Problem reproduzieren lässt.

• Problem beschreiben, keinen Lösungsvorschlag in den Titel schreiben.

Was sagt die Forschung zu guten Bug Reports?

Entwickler brauchen andere Angaben, als Nutzer liefern: Die Auswertung von 466 Antworten aus den Projekten Apache, Eclipse und Mozilla zeigte eine „information mismatch between what developers need and what users supply“. Die meisten Entwickler halten Schritte zur Reproduktion, Stack Traces und Testfälle für hilfreich, und genau diese Angaben fallen Nutzern am schwersten (Zimmermann et al., IEEE TSE, 2010).

Fehlende Reproduzierbarkeit kostet Zeit. In der MSR-Studie von Joorabchi, Mirzaaghaei und Mesbah machten nicht reproduzierbare Berichte 17 % aller Berichte in den untersuchten Repositories aus und blieben rund drei Monate länger aktiv als andere (Joorabchi et al., MSR, 2014). Präzise Schritte, eine vollständige Umgebungsangabe und benannte Testdaten geben dem Entwickler, was er zum Nachstellen braucht.

Wie schreiben Sie eine gute Zusammenfassung?

Eine gute Zusammenfassung nennt Symptom, Ort und Bedingung in weniger als 60 Zeichen. Laut Mozilla soll sie einen Bericht schnell und eindeutig identifizieren: „It should explain the problem, not your suggested solution.“ Mozillas eigenes Beispielpaar lautet „Cancelling a File Copy dialog crashes File Manager“ (gut) und „Software crashes“ (schlecht) (Mozilla Bug Writing Guidelines, abgerufen 2026).

Abbildung 3: Schwache vs. bessere Zusammenfassung (Beispiele)

Testfall oder Fehlerbericht: Was gehört wohin?

Ein Testfall legt vor der Ausführung fest, was geprüft wird und welches Ergebnis zu erwarten ist; ein Fehlerbericht dokumentiert danach eine Abweichung von diesem Ergebnis. Der Testfall bleibt über viele Testläufe gültig. Der Fehlerbericht entsteht erst bei einer Fehlerwirkung und wird geschlossen, sobald sie behoben oder anders entschieden ist. Aufbau und Felder beschreibt der Beitrag Testfall: Vorlage und Beispiele.

Beide Dokumente hängen zusammen. Der Lehrplan führt den Testfall im Fehlerbericht als Kontext und als Referenz auf. In der Praxis kopieren Sie Vorbedingungen und Schritte aus dem Testfall, ergänzen das tatsächliche Ergebnis und verweisen auf die Testfall-ID. Liegen die Testausführungen in Jira, verknüpfen Sie den Bericht direkt mit der fehlgeschlagenen Ausführung, wie im Beitrag zu Testmanagement mit Xray in Jira beschrieben.

Was liefert ein automatisierter Testlauf für den Fehlerbericht?

Ein fehlgeschlagener automatisierter Testlauf liefert einen Großteil der Angaben, die die meisten Entwickler laut Zimmermann et al. für hilfreich halten: die Schritte zur Reproduktion, den Testfall selbst und, je nach Framework, einen Stack Trace (eine Einordnung der Redaktion, keine Messung).

Abbildung 4: Vom fehlgeschlagenen Testlauf zum Fehlerbericht

Vor dem Bericht steht die Prüfung, ob der Fehler im Produkt liegt. Bei Google meldeten rund 1,5 % aller Testläufe ein „flaky“ Ergebnis (Google Testing Blog, 2016). Rund 84 % der beobachteten Wechsel von bestanden auf fehlgeschlagen betrafen einen flaky Test (Google Testing Blog, 2016).

Autemos ist eine KI-gestützte Software für funktionale Testautomatisierung über Web, Mobile, API und Desktop. Autemos ist kein Defect-Tracker. Es ersetzt Jira, Azure DevOps oder Bugzilla nicht und legt keine Bug-Tickets automatisch an. Fehlerschweregrad, Priorität und die Grundursachenanalyse bleiben Aufgaben Ihres Teams. Ein fehlgeschlagener Autemos-Lauf liefert folgende Belege:

• Der visuelle Test-Workflow ist die Schrittfolge, ein fehlgeschlagener Lauf lässt sich damit wiederholen.

• Web-Tests lassen sich als Playwright-Code, Mobile-Tests als Appium-Code exportieren. Der Code läuft ohne Autemos, Entwickler können den Lauf damit außerhalb des Tools wiederholen.

• Ergebnisse landen in Autemos-Reports und Allure-Reports, Logs und Telemetrie können an Splunk oder Dynatrace gehen.

• Testausführungen synchronisieren bidirektional mit Jira/Xray.

• Die Konfiguration pro Umgebung (DEV, TEST, STAGING, PROD) hält fest, wo der Lauf stattfand.

• Jede Self-Healing-Aktion steht im Report und lässt sich prüfen, ablehnen oder zurücknehmen. Ein geänderter Locator erscheint so als Änderung am Test, nicht als Produktfehler.

Ist ein Fehler behoben, kann der KI-Chat aus dem Jira-Ticket einen Test-Workflow für den Regressionstest entwerfen. Jeder KI-generierte Schritt braucht vor der Ausführung die Freigabe des Teams.

Vorlagen in GitHub und Jira

Issue-Tracker erzwingen Felder über Formulare. GitHub Issue Forms erlauben laut Dokumentation verschiedene Eingabetypen, Pflichtprüfungen, Standard-Zuständige und Standard-Labels. Ein Feld wird über die Einstellung „required: true“ zur Pflicht (GitHub Docs, abgerufen 2026). Atlassian hat eine Jira-Vorlage für Bug Reports mit Zusammenfassung, Schritten, erwartetem und tatsächlichem Ergebnis, Umgebung und Schweregrad. Welche Testmanagement-Tools solche Formulare mitbringen, steht im Tool-Vergleich.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Fehlerbericht und Bug Report?

Es gibt keinen: Bug Report ist der englische Begriff für den Fehlerbericht. Das ISTQB-Glossar führt „bug report“ als Synonym von „defect report“, die Norm ISO/IEC/IEEE 29119-3 spricht von Abweichungsberichten („incident reports“).

Welche Angaben sind in einem Fehlerbericht am wichtigsten?

Die Schritte zur Reproduktion sind laut Mozilla der wichtigste Teil jedes Bug Reports. Danach folgen erwartetes und tatsächliches Ergebnis, die Testumgebung mit Version oder Build und Belege wie Protokolle, Stack Traces oder Screenshots.

Wer setzt Fehlerschweregrad und Priorität?

Fehlerschweregrad und Priorität legt der Fehlermanagement-Prozess Ihres Teams fest. Bei Mozilla setzt das QA-Team für Bugs, die QA gemeldet oder reproduziert hat, einen initialen Schweregrad, und jede Änderung braucht einen Kommentar mit Begründung (Mozilla Triage-Richtlinie, abgerufen 2026). Mozilla bewertet den Schweregrad auf einer vierstufigen Skala von S1 bis S4 (Mozilla BMO User Guide, abgerufen 2026).

Was tun, wenn sich ein Fehler nicht reproduzieren lässt?

Einen nicht reproduzierbaren Fehler melden Sie trotzdem, mit der Angabe, ob er sich jederzeit, gelegentlich oder gar nicht reproduzieren lässt, so wie Mozilla es verlangt. Hängen Sie den Zeitpunkt und die Protokolle an, bei datengetriebenen Tests den Testdatensatz dazu. Nicht reproduzierbare Berichte machten in einer MSR-Studie von 2014 17 % aus und blieben rund drei Monate länger aktiv.

Legt Autemos automatisch Fehlerberichte an?

Nein, Autemos legt keine Bug-Tickets an. Es liefert Material für den Bericht: reproduzierbare Test-Workflows, Autemos- und Allure-Reports, mit Jira/Xray synchronisierte Testausführungen und dokumentierte Self-Healing-Aktionen. Den Fehlerbericht schreibt und bewertet Ihr Team im eigenen Tracker.

Fazit

Ein guter Fehlerbericht lässt sich ohne Rückfrage nachstellen. Die elf Felder aus dem CTFL-Lehrplan geben die Struktur vor, Mozillas Regeln die Qualität: Schritte zuerst, ein Problem pro Bericht, Fakten getrennt von Vermutungen und eine Zusammenfassung, die das Problem beschreibt. In einer MSR-Studie machten nicht reproduzierbare Berichte 17 % aus und blieben dort rund drei Monate länger aktiv.

Übernehmen Sie die Vorlage in Ihr Formular in Jira, GitHub oder Azure DevOps und verknüpfen Sie jeden Bericht mit dem Testfall. Wie es nach dem Bericht weitergeht, zeigt der Überblick zum Fehlermanagement. Wenn Sie sehen möchten, wie fehlgeschlagene Autemos-Läufe reproduzierbare Schritte und Belege für die Berichte Ihres Teams liefern, vereinbaren Sie eine Demo.