Bug Report schreiben: Vorlage, Beispiele & Best Practices (2026)

Ein Bug Report ist die wichtigste Übersetzungsleistung zwischen Test und Entwicklung. Schlecht geschrieben kostet er Sie pro Vorfall eine halbe Stunde Rückfrage, Reproduktion und Statuswechsel. Gut geschrieben ist der Bug nach 20 Minuten reproduziert, eingeordnet und im Sprint-Backlog priorisiert.

In der Praxis sehen wir bei Qytera einen konstanten Hebel: Teams, die ihre Bug Reports auf zehn Pflichtfelder und eine wiederholbare Vorlage standardisieren, senken ihre Triage-Zeit um den Faktor drei bis vier. Der Rest ist Disziplin und ein gutes Tracking-Tool.

Dieser Leitfaden zeigt Ihnen, wie Sie effektive Bug Reports schreiben: mit ISTQB-konformer Begriffsabgrenzung, kopierfertiger Vorlage, Best Practices, einer klaren Severity-vs.-Priority-Logik und einem ehrlichen Vergleich der gängigen Bug-Tracking-Tools.

Was ist ein Bug? Definition und Abgrenzung

Ein Bug ist im Sprachgebrauch der Software-Praxis ein Sammelbegriff für alles, was sich anders verhält als spezifiziert. In der ISTQB-Terminologie heißt der saubere Begriff Fehlerzustand (englisch defect): eine Unzulänglichkeit oder ein Mangel in einem Arbeitsergebnis, sodass es seine Anforderungen oder Spezifikationen nicht erfüllt.

Das ISTQB-Glossar unterscheidet drei Begriffe, die Sie im Bug Report sauber halten sollten:

• Fehlhandlung (Error): eine menschliche Handlung, die zu einem falschen Ergebnis führt. Beispiel: ein Entwickler vertauscht in einer Berechnung zwei Variablen.
• Fehlerzustand (Defect / Bug): die statische Unzulänglichkeit im Code oder Dokument, die aus der Fehlhandlung entsteht.
• Fehlerwirkung (Failure): das beobachtbare Ereignis zur Laufzeit, etwa eine falsche Summe in der Rechnung oder ein abgestürztes Modul.

Ein Bug Report dokumentiert in der Regel eine Fehlerwirkung, denn das ist, was im Test sichtbar wird. Der Fehlerzustand selbst wird erst durch das Debugging entdeckt. Diese Unterscheidung wirkt akademisch, sie zahlt sich aber in jedem Audit-Gespräch aus.

Abzugrenzen ist der Bug vom Mangel: ein Mangel liegt vor, wenn eine berechtigte Erwartung nicht erfüllt ist, obwohl die Anforderung formal eingehalten wird. Beispiel: die Buchungsmaske akzeptiert „31. Februar" als gültiges Datum, weil die Validierung nicht spezifiziert war. Technisch kein Bug, fachlich sehr wohl ein Problem.

Warum Bug Tracking und Bug Reporting wichtig ist

Komplexe Software lässt sich selten von einer Person komplett überblicken. Entwicklung, Test, Produktmanagement und Support arbeiten an verschiedenen Stellen am selben System, oft in verschiedenen Zeitzonen. Der Bug Report ist das Artefakt, das diese Rollen synchronisiert.

Drei harte Effekte beobachten wir in Kundenprojekten:

• Reproduktionsdauer: ein Bug ohne klare Schritte kostet im Schnitt 45 bis 90 Minuten Entwickler-Zeit für Nachfragen und Rumprobieren. Ein Bug mit präzisen Steps to Reproduce ist in 10 bis 20 Minuten im Debugger.
• Priorisierung: ohne Severity-Klassifikation entscheidet das lauteste Stakeholder-Argument. Mit Severity und Priority entscheidet die Datenlage.
• Audit-Trail: in regulierten Branchen (Finanzen, Healthcare, Bahn) ist die lückenlose Dokumentation von Fehlerzuständen und ihrer Behebung Pflicht. Ein sauberes Bug-Tracking-Tool liefert das ohne Zusatzaufwand.

Wer Bug Reports als Nebenarbeit behandelt, zahlt diesen Aufwand später dreifach: in Nachfragen, in Eskalationen und in fehlenden Belegen, wenn ein Kunde eine Reklamation einreicht.

Aufbau eines Bug Reports: 10 Pflichtfelder

Jeder Bug Report sollte diese zehn Felder enthalten. Die Reihenfolge ist bewährt: zuerst die Klassifikation, dann die Reproduktion, am Ende die Anhänge.

Die Felder Severity und Priority werden in der Praxis am häufigsten verwechselt. Wir kommen weiter unten zurück darauf.

Bug Report Vorlage zum Kopieren

Diese Vorlage hat sich in Kundenprojekten als robust erwiesen. Sie funktioniert in jedem Tracker, der Markdown oder Rich-Text unterstützt: Jira, Azure DevOps, GitHub Issues, GitLab, Mantis, Redmine.

## Titel
[Komponente] Symptom in einem Satz

## Klassifikation
- Severity: Blocker | Critical | Major | Minor | Trivial
- Priority: P1 | P2 | P3
- Build / Version: x.y.z
- Umgebung: DEV | TEST | STAGE | PROD

## Kurze Beschreibung
Zwei bis drei Sätze: was, wo, ab wann beobachtet.

## Steps to Reproduce
1.
2.
3.

## Expected Result


## Actual Result


## Environment
- App-Version:
- Browser / Client:
- OS:
- Backend / DB:
- Testdaten:

## Attachments
- screenshot.png
- network.har
- app.log

## Verknüpfungen
- Testfall: TC-
- User Story: US-
- Verwandte Tickets:

Ein ausgefülltes Beispiel:

## Titel
[Login] HTTP 500 bei Passwörtern mit Sonderzeichen ! oder ?

## Klassifikation
- Severity: Critical
- Priority: P1
- Build: 3.4.1
- Umgebung: STAGE

## Kurze Beschreibung
Der Login-Endpunkt /api/v1/login antwortet mit HTTP 500, sobald das Passwort
ein Ausrufezeichen oder Fragezeichen enthält. Reproduzierbar seit Build 3.4.1
(rolling deploy 10. Juni 14:30 Uhr).

## Steps to Reproduce
1. https://stage.example.com/login öffnen
2. Mail testuser@example.com eingeben
3. Passwort Test!2026 eingeben
4. Button „Anmelden" klicken

## Expected Result
HTTP 200, Weiterleitung auf /dashboard.

## Actual Result
HTTP 500, leere Antwort, Stacktrace in app.log Zeile 4711:
java.lang.IllegalArgumentException: Invalid URL-encoded character

## Environment
- App-Version: 3.4.1
- Browser: Chrome 126.0.6478.55
- OS: macOS 14.5
- Backend: PostgreSQL 16, JVM 21
- Testdaten: stage-fixture-set-7

## Attachments
- login-500.png
- chrome-network.har
- app-log-excerpt.txt

## Verknüpfungen
- Testfall: TC-457
- User Story: US-123 (Login-Hardening)
- Verwandte Tickets: BUG-4002 (Special-Char-Handling Registrierung)

Best Practices für effektive Bug Reports

Sieben Regeln, die wir in Kundenprojekten konsequent durchsetzen:

1. Ein Bug, ein Report. Mehrere Befunde im selben Ticket sind unbearbeitbar. Wenn beim Schreiben ein zweites Symptom auftaucht: zweites Ticket aufmachen, gegenseitig verknüpfen.
2. Vor dem Absenden reproduzieren. Mindestens einmal komplett neu, idealerweise auf einem zweiten Gerät oder mit einem Kollegen. Ein nicht reproduzierbarer Bug ist im Tracker tot.
3. Sachlich formulieren. Kein „funktioniert nicht", sondern was Sie erwartet haben und was tatsächlich passiert ist. Keine Schuldzuweisungen, keine Vermutungen über die Ursache im Titel.
4. Steps to Reproduce als Aktion, nicht als Roman. Jeder Schritt eine Aktion (klicken, eingeben, warten). Keine kombinierten Sätze.
5. Screenshots und Videos statt Beschreibung. Ein Screenshot mit Markierung ersetzt drei Absätze Text. Ein 30-Sekunden-Video ersetzt eine Stunde Rückfragen.
6. Logs als Auszug, nicht als 200-MB-Dump. Stacktrace plus 30 Zeilen Kontext reichen. Vollständige Logs nur auf Nachfrage anhängen.
7. Lebenszyklus aktiv pflegen. Status nach Verifikation umsetzen, nicht warten. Geschlossene Bugs ohne Verifikation sind eine tickende Zeitbombe für das nächste Release.

Severity vs. Priority: die häufigste Verwechslung

Severity beschreibt den technischen Schweregrad: wie stark beeinträchtigt der Bug das System. Priority beschreibt die Bearbeitungsreihenfolge: wann muss der Bug behoben sein. Beides ist unabhängig voneinander.

Die Verwechslung tritt fast immer in dieselbe Richtung auf: Tester setzen Severity hoch, weil der Bug sie nervt. Korrekt ist Severity nach Spec-Verletzung, Priority nach Geschäftsauswirkung.

Bug Tracking Tools im Vergleich

Die Tool-Auswahl folgt dem Team-Setup, nicht umgekehrt. Vier Kandidaten decken 90 Prozent unserer Kundenprojekte ab.

Wichtig: jedes Tool ist nur so gut wie der Workflow, der dahintersteht. Wir empfehlen, vor der Tool-Entscheidung einen Workflow-Workshop zu führen und die Status-Übergänge (New, In Progress, Ready for Test, Verified, Closed) explizit zu modellieren.

Bug Reports und Testautomatisierung

Automatisierte Tests sind die zuverlässigste Quelle für gut reproduzierbare Bug Reports. Ein fehlgeschlagener Test in der CI/CD-Pipeline liefert frei Haus: Steps to Reproduce als Testcode, Expected vs. Actual als Assertion-Output, Environment als Pipeline-Metadaten, oft auch Screenshot und Video.

In Kundenprojekten setzen wir auf drei Pattern:

• Playwright und Cypress: automatische Screenshot- und Video-Aufzeichnung bei Test-Failure. Der CI-Job lädt sie als Artefakte hoch, der Bug Report verlinkt direkt darauf.
• Cucumber und BDD: Gherkin-Szenarien lesen sich wie Steps to Reproduce. Ein fehlgeschlagenes Scenario kann direkt in den Bug Report kopiert werden.
• API-Tests (z. B. mit Postman oder REST Assured): Request, Response und Assertion liefern die komplette Reproduktionsbasis. Besonders nützlich, wenn der Bug nicht im UI, sondern in der API-Schicht steckt.

Wer mehr darüber lesen möchte, wie wir Testautomatisierung in Kundenprojekten aufsetzen, findet eine ausführliche Anleitung in unserem Beitrag Testautomatisierung: 10 goldene Regeln aus der Praxis. Für die Frage, wie Bug Tracking in eine ganzheitliche Quality-Engineering-Strategie passt, lohnt sich der Hub-Beitrag Software Testing: Grundlagen und Methoden.

Fazit

Ein guter Bug Report ist kein Pflichtformular, sondern ein Werkzeug, das die Triage-Zeit halbiert und die Verifikation beschleunigt. Die zehn Pflichtfelder, die Vorlage und die Severity-vs.-Priority-Logik aus diesem Leitfaden geben Ihnen einen wiederholbaren Standard, der in Jira, Azure DevOps, GitHub Issues und Mantis gleichermaßen funktioniert.

Wenn Sie Bug Tracking und Testautomatisierung in Ihrer Organisation auf ein gemeinsames Niveau heben möchten, unterstützen wir Sie gerne mit einem Quality-Engineering-Audit oder einem Workshop für QA-Teams. Sprechen Sie uns an.

FAQ zu Bug Reports

Was ist ein Bug Report?

Ein Bug Report dokumentiert das Auftreten, die Art und den Status eines Fehlerzustands. In der ISTQB-Terminologie heißt er defect report (Fehlerbericht). Er bündelt alle Informationen, die ein Entwickler braucht, um den Bug zu reproduzieren, einzuordnen und zu beheben, ohne nachzufragen.

Welche Pflichtfelder sollte ein Bug Report enthalten?

Zehn Felder haben sich bewährt: Titel, Severity, Priority, Kurze Beschreibung, Steps to Reproduce, Expected Result, Actual Result, Environment, Attachments und Verknüpfungen zu Testfall und User Story. Die Vorlage in diesem Beitrag enthält alle zehn als kopierfertiges Markdown.

Was ist der Unterschied zwischen Severity und Priority?

Severity beschreibt den technischen Schweregrad eines Bugs (wie stark er das System beeinträchtigt). Priority beschreibt die Bearbeitungsreihenfolge (wann er behoben sein muss). Ein Bug kann hohe Severity und niedrige Priority haben (interner Admin-Crash) oder umgekehrt (Logo-Tippfehler vom CEO entdeckt).

Was ist der Unterschied zwischen Bug, Fehlerzustand und Fehlerwirkung?

Das ISTQB-Glossar unterscheidet: Fehlhandlung (Error) ist die menschliche Handlung, die den Defekt verursacht. Fehlerzustand (Defect, umgangssprachlich Bug) ist die statische Unzulänglichkeit im Code. Fehlerwirkung (Failure) ist das beobachtbare Fehlverhalten zur Laufzeit. Ein Bug Report dokumentiert in der Regel eine Fehlerwirkung.

Welches Bug Tracking Tool eignet sich für mein Team?

Jira eignet sich für Enterprise-Setups mit komplexen Workflows. Azure DevOps passt zum Microsoft-Stack. GitHub Issues und GitLab sind ideal für code-nahes Tracking in kleinen Teams. Mantis BT und Redmine sind sinnvoll, wenn Sie self-hosted ohne Vendor-Lock-in arbeiten wollen.

Können automatisierte Tests Bug Reports ersetzen?

Sie ersetzen den Bug Report nicht, aber sie liefern die zuverlässigste Reproduktionsbasis. Playwright und Cypress speichern Screenshots und Videos bei Test-Failure automatisch. Cucumber-Szenarien lesen sich wie Steps to Reproduce. Der manuelle Bug Report bleibt nötig für Befunde, die der automatisierte Test noch nicht abdeckt.