Warum das Format öfter übersehen wird als der Inhalt
Ein Bug-Berichtsformat besteht aus 10 festen Feldern in vier Gruppen: Identität → Umgebung → Symptom → Nachweise. Ist die Reihenfolge fix, weiß ein Entwickler sofort, wo er suchen muss — ohne ein zweites Mal nachzufragen. Unten findest du die vollständige Feldliste, Schreibregeln mit guten und schlechten Beispielen je Feld und die 7 Formatfehler, die ansonsten solide Berichte still zerstören.
Dieselbe Information in einem anderen Format kostet doppelt so viel Verarbeitungszeit. Uneinheitliche Formate verursachen drei Probleme:
Der Wert eines Formats liegt nicht darin, dass es aufgeräumt aussieht, sondern darin, dass dasselbe Feld immer an derselben Stelle steht.
Das Standardformat für Bug-Berichte: 10 Felder
| # | Feld | Zweck | Pflicht? | So schreibst du es |
|---|---|---|---|---|
| 1 | Titel | Lässt Entwickler entscheiden, ob sie das Ticket öffnen | Pflicht | Komponente + Aktion + unerwartetes Ergebnis + Bedingung (siehe Beispiele für Bug-Titel) |
| 2 | ID | Lässt alle dieselbe Meldung referenzieren | Pflicht (automatisch) | BUG-0042, nie „das von vorhin" |
| 3 | Schweregrad / Priorität | Grundlage für die Planung | Empfohlen | Schweregrad misst den Schaden, Priorität die Dringlichkeit — getrennt halten |
| 4 | Umgebung | Entscheidet, ob der Bericht reproduzierbar ist | Pflicht | URL, Browserversion, Betriebssystem, Gerät, Auflösung, Konto |
| 5 | Vorbedingungen | Der Startzustand für die Reproduktion | Empfohlen | „Als Enterprise-Konto angemeldet, 2 Artikel liegen bereits im Warenkorb" |
| 6 | Schritte zur Reproduktion | Führt jemanden zum selben Bildschirm | Pflicht | Nummeriert, eine Aktion pro Schritt (siehe Reproduktionsschritte schreiben) |
| 7 | Erwartetes Ergebnis | Grundlage für „ist das ein Defekt?" | Pflicht | Beschreibe, was passieren sollte, nie „funktioniert nicht richtig" |
| 8 | Tatsächliches Ergebnis | Sachliche Beschreibung | Pflicht | Symptom + Zahlen + exakter Fehlertext, ohne Spekulation |
| 9 | Nachweise | Erspart dem Entwickler einen kompletten Neuversuch | Dringend empfohlen | Annotierte Screenshots, Bildschirmaufnahme, Konsolen-Logs, fehlgeschlagene Requests |
| 10 | Notizen | Zusätzlicher Kontext | Optional | Häufigkeit, Workarounds, verwandte Tickets |
So schreibst du die einzelnen Felder
Identität: Titel, ID, Schweregrad und Priorität
- Titel: eine Zeile mit wo, was du getan hast, was schiefging und unter welcher Bedingung. 40 gute und schlechte Beispiele im Vergleich: Beispiele für Bug-Titel.
- ID: lass sie vom System erzeugen. Manuelle Nummerierung erzeugt immer Doppelungen.
- Schweregrad vs. Priorität: das Paar, das am häufigsten zu einem Feld verschmilzt.
| Feld | Beantwortet die Frage | Wer entscheidet | Beispiel |
|---|---|---|---|
| Schweregrad | Wie groß ist der Schaden des Defekts selbst? | Tester / Melder | Datenverlust = kritisch; ein Tippfehler = gering |
| Priorität | Wann beheben wir ihn? | Produkt / Tech Lead | Tippfehler im Hero-Bereich in der Launch-Woche = hohe Priorität |
Umgebung: Umgebung und Vorbedingungen
Das Umgebungsfeld muss alle sechs Angaben enthalten: URL, Browser und Version, Betriebssystem, Gerät, Auflösung bzw. Viewport und Kontotyp. „Chrome" allein ist so gut wie nichts — Verhaltensunterschiede zwischen Browserversionen sind im Web Alltag.
Die Vorbedingung, die am häufigsten fehlt, ist nicht der Login-Status, sondern der Datenzustand: „2 Artikel liegen im Warenkorb", „Konto ist am 3. Tag der Testphase", „für diese Bestellung wurde bereits einmal erstattet". Genau daran scheitert die Reproduktion.
Symptom: Schritte zur Reproduktion, erwartetes und tatsächliches Ergebnis
- Schritte zur Reproduktion: nummeriert, eine Aktion pro Schritt, echte Daten. Die vollständige Methode steht unter Reproduktionsschritte schreiben.
- Erwartetes Ergebnis: Beschreibe, was passieren sollte, und belege es möglichst (Anforderung, Kennung eines Abnahmekriteriums oder schlicht Fachlogik). „Es sollte richtig funktionieren" schiebt die Bewertung zum Entwickler zurück.
- Tatsächliches Ergebnis: nur Fakten, mit Zahlen und dem exakten Fehlertext. Keine Spekulation — Vermutungen wie „wahrscheinlich ein Caching-Problem" gehören in die Notizen, markiert als „vermutet".
Nachweise: Screenshots / Aufnahmen / Logs und Notizen
- Screenshots müssen annotiert sein: markiere den Problembereich und ergänze Pfeile oder Text, damit niemand einen ganzen Vollbildschirm durchsucht.
- Bildschirmaufnahmen sollten 10–30 Sekunden dauern und nur den relevanten Moment zeigen — eine fünfminütige Aufnahme wird meist nicht angesehen.
- Logs sollten nur das Nützliche enthalten: Konsolenausgaben auf Fehlerlevel, fehlgeschlagene Netzwerkanfragen (HTTP ≥ 400) sowie Request- und Response-Body des entscheidenden Endpunkts.
- Notizen sollten zwei Dinge tragen: die Häufigkeit (immer / sporadisch, mit Wahrscheinlichkeit) und einen Workaround.
Formatunterschiede in drei Kanälen
| Kanal | Darstellung der Felder | Die Falle |
|---|---|---|
| Issue-Tracker (Jira / Linear / GitHub Issues) | Eigene Felder plus Beschreibungsvorlage | Umgebungsinfos stehen am Ende der Beschreibung und versinken im Langtext — sie gehören in eigene Felder |
| E-Mail oder Chat (an Kunden oder externe Mitwirkende) | Reine Textblöcke | Kein TL;DR, und Anhänge heißen beliebig, sodass Empfänger ein Dutzend Dateien durchsuchen |
| Tabelle (Excel / Google Sheets / Feishu Bitable) | Eine Zeile pro Bug, Spalten = Felder | Die Spaltenreihenfolge passt nicht zu den 10 Feldern, Filtern und Sortieren brechen |
Der Kanal wechselt, die Felder nicht. Fehlende Informationen werden nicht verziehen, nur weil sie per E-Mail kamen.
7 Formatfehler, die einen Bericht ruinieren
screenshot-1.png, die der Melder drei Tage später selbst nicht mehr zuordnen kann.Format-Checkliste
Prüfe vor dem Absenden jede Zeile:
- Alle 10 Felder vorhanden, in derselben Reihenfolge wie zuletzt?
- Alle sechs Umgebungsangaben (URL / Browser / OS / Gerät / Auflösung / Konto) gefüllt?
- Erwartetes und tatsächliches Ergebnis getrennt geschrieben?
- Schritte nummeriert, eine Aktion pro Schritt?
- Screenshots annotiert und Aufnahmen unter 30 Sekunden?
- Keine unbestätigte Spekulation im tatsächlichen Ergebnis?
- Häufigkeit klar angegeben (immer / sporadisch + Wahrscheinlichkeit)?
FAQ
Gibt es ein „Standardformat" für Bug-Berichte?
Ein verbindlicher Branchenstandard existiert nicht, aber es gibt einen faktischen Konsens: Titel, Umgebung, Reproduktionsschritte, erwartetes Ergebnis, tatsächliches Ergebnis und Nachweise tauchen in praktisch jedem Rahmenwerk auf (IEEE 829, ISTQB und die meisten kommerziellen Defektvorlagen). Die 10 Felder hier ergänzen diesen Kern um Identitäts- und Notizfelder.
Dürfen wir die Feldreihenfolge ändern?
Ja, solange sie im Team konsistent und stabil bleibt. Der Sinn einer festen Reihenfolge ist Muskelgedächtnis — Entwickler wissen, wo sie scannen. Häufige Änderungen schaden mehr, als eine suboptimale Reihenfolge kostet.
Was ist der echte Unterschied zwischen Schweregrad und Priorität?
Der Schweregrad beschreibt den objektiven Schaden des Defekts (bewertet im Test), die Priorität die Dringlichkeit der Behebung (bewertet im Produkt). Beide können auseinandergehen: Ein Tippfehler im Hero-Bereich hat einen geringen Schweregrad, aber wenn der Launch in drei Tagen ist, ist seine Priorität hoch.
Brauchen einfache Bugs wirklich alle 10 Felder?
Nein. Ein einfacher Bug kommt mit Titel, Umgebung und tatsächlichem Ergebnis aus — aber die Umgebung darf nie fehlen, sie ist die häufigste Ursache für „kann nicht reproduziert werden". Felder sind optional, Positionen nicht.
Was ist der Unterschied zwischen einem „Format" und einer „Vorlage"?
Ein Format ist die Feldspezifikation: welche Felder es gibt, in welcher Reihenfolge und wie jedes ausgefüllt wird. Eine Vorlage ist eine Skelettdatei zum Kopieren und Ausfüllen. Beides greift ineinander — Felder per Format definieren, dann als Vorlage ausliefern. Das Gerüst zum Ausfüllen findest du unter Bug-Bericht-Vorlage (mit Word- und Markdown-Version).
Das Format kann automatisch entstehen — die Bewertung bleibt bei dir
Zur Klarstellung der Grenze: BugCapturer entscheidet nicht, was ein Defekt ist, und schreibt auch keinen Titel — dafür braucht es dein Verständnis des Beobachteten. Was aber vergessen wird und Zeit frisst, kann sich selbst füllen:
- Automatischer technischer Kontext: URL, Browser, Betriebssystem, Auflösung und Viewport werden direkt ins Umgebungsfeld geschrieben, kein Abtippen nötig.
- Diagnosedaten: Konsolen-Logs auf Fehlerlevel und fehlgeschlagene Netzwerkanfragen (HTTP ≥ 400) werden gesammelt, sensible Parameter (Tokens, Passwörter, API-Keys) automatisch unkenntlich gemacht.
- Annotierte Screenshots: Bereich markieren, dann Pfeile, Rahmen und Text ergänzen — „wo es falsch ist" steckt fest im Bild.
- Bildschirmaufnahme: aktuellen Tab aufnehmen und den Ausschnitt kürzen, sodass Entwickler ein kurzes, prüfbares Video erhalten.
- Teilen oder synchronisieren: einen Freigabelink erzeugen, den externe Mitwirkende ohne Registrierung öffnen, oder den Bericht in eine Feishu-Base bzw. einen generischen Webhook schicken.
Die Bewertung bleibt bei dir. Den Rest übernimmt das Tool.
Weiterlesen
- Bug-Bericht-Vorlage: alle Felder mit kopierfertigem Gerüst
- Beispiele für Bug-Titel: 40 gute und schlechte Titel im Vergleich
- Reproduktionsschritte schreiben: 5 vollständige Beispiele
- Bugs effektiv melden
- Website-QA-Checkliste