Die Vorlage für Fehlerberichte, die funktioniert (und wie du sie überflüssig machst)

QADenis Povarov25. August 2026

Such nach „Bug-Report-Vorlage“, und du findest hundert Varianten desselben Formulars. Titel, Umgebung, Schritte zur Reproduktion, erwartetes Ergebnis, tatsächliches Ergebnis, Schweregrad, Screenshots. Kopier es in deinen Issue-Tracker, und nach einem Monat füllt es so gut wie niemand mehr aus.

Meist wird das als Disziplinproblem diagnostiziert. Das ist es nicht. Es ist ein Designproblem: Die Vorlage verlangt von einem Menschen, Informationen abzuschreiben, die eine Maschine längst hat, und Menschen weigern sich zu Recht, mühsame Arbeit ohne sichtbaren Nutzen zu machen.

Deshalb hat dieser Text zwei Hälften. Zuerst eine Vorlage zum Kopieren, die sich zu behalten lohnt. Dann das nützlichere Argument: welche Felder du löschen solltest, weil etwas anderes sie ausfüllen sollte.

Die Vorlage

## Zusammenfassung
Ein Satz. Was kaputt ist, so wie man es von außen sieht.

## Schritte zur Reproduktion
1.
2.
3.

## Erwartet
Was du erwartet hast.

## Tatsächlich
Was stattdessen passiert ist.

## Auswirkung
Wer ist betroffen, wie oft, und gibt es einen Workaround?

## Umgebung
Browser / Betriebssystem / Gerät / App-Version / URL / Art des angemeldeten Accounts

## Belege
Screenshot, Aufnahme, Console-Ausgabe, fehlgeschlagener Request, Request-ID

Das ist alles. Neu ist hier nichts. Der Wert liegt darin, wozu jedes Feld eigentlich da ist, und genau da liegen die meisten Vorlagen daneben.

Zusammenfassung

Das am häufigsten verpfuschte Feld. Eine gute Zusammenfassung ist von außen geschrieben: „Der Checkout-Button tut im Zahlungsschritt bei gespeicherten Karten nichts.“ Eine schlechte ist aus einer Vermutung heraus geschrieben: „Race Condition beim Stripe-Token.“

Vermutungen im Titel richten Schaden an, weil sie alle, die den Bericht danach lesen, auf eine Spur festlegen. Bei schlecht betitelten Bugs geht die Hälfte der Triage-Zeit dafür drauf, eine Diagnose zu widerlegen, die sich die meldende Person ausgedacht und niemand hinterfragt hat.

Frag nach der Beobachtung. Die Diagnose stellt, wer den Bug behebt.

Schritte zur Reproduktion

Das Feld, von dem alle wissen, dass es wichtig ist, und das fast alle schlecht ausfüllen, und zwar auf eine ganz bestimmte Art: Beim Melden schreibt man die Schritte auf, die man für relevant hält, nicht die, die man gemacht hat.

Weggelassen wird „Ich hatte zwei Tabs offen.“ Weggelassen wird „Ich war schon etwa eine Stunde auf der Seite.“ Weggelassen wird „Ich kam über den Link in der E-Mail, nicht über die Navigation.“ Genau diese Auslassungen sind meistens der Bug.

Die Anweisung, die hilft: Schreib auf, was du getan hast, ab dem Öffnen der Seite, auch die langweiligen Teile.

Der Ausgangszustand zählt so viel wie die Aktionen. Angemeldet mit welcher Rolle? Mit welchen Daten schon im Account? In welchem Plan? Wer mit einem frischen Account reproduziert, sieht den Bug oft gar nicht.

Erwartet und tatsächlich

Neben der Zusammenfassung wirken die beiden überflüssig. Behalte sie trotzdem.

Die Trennung fängt eine ganze Klasse von Berichten ab, die keine Bugs sind: Fälle, in denen die Software genau wie vorgesehen funktioniert und die Person etwas anderes erwartet hat. Das ist real und wissenswert, denn es ist ein Fehler in der Dokumentation, in der UX oder im Verkaufsversprechen. Ein Fehler im Code ist es aber nicht, und es ist enorm viel billiger, das bei der Triage zu erkennen als nach zwei Tagen Untersuchung.

Das Paar erzwingt außerdem Genauigkeit. „Es geht nicht“ überlebt die Aufteilung in erwartet und tatsächlich nicht. Eines der beiden Felder vage zu lassen, wäre peinlich.

Auswirkung

Das Feld, das die meisten Vorlagen weglassen, und das, das am stärksten bestimmt, was als Nächstes passiert.

Dropdowns für den Schweregrad funktionieren nicht. Alle wählen „Hoch“, weil aus der eigenen blockierten Aufgabe heraus alles hoch ist. Frag stattdessen nach den drei Dingen, die der Schweregrad grob abbilden soll:

Wer: nur ich, mein ganzes Team, alle, die Safari benutzen?
Wie oft: einmal, jedes Mal, ungefähr jedes zehnte Mal?
Workaround: Gibt es einen anderen Weg, die Sache zu erledigen?

„Jedes Mal, alle auf Mobilgeräten, kein Workaround“ und „einmal, nur ich, Neuladen hilft“ sortieren sich von selbst, ohne dass jemand ein Dropdown anfasst. Und „jedes zehnte Mal“ leistet mehr, als man denkt: Sporadisch heißt Race Condition, Caching oder Lastabhängigkeit, und das sagt dem Entwicklungsteam, wo es suchen soll, bevor es überhaupt angefangen hat.

Umgebung

Notwendig, und auf dieser Liste die schlechteste Verwendung menschlicher Zeit. Merk dir das für später.

Belege

Screenshots sind der Standard, und sie sind die schwächste gängige Form von Belegen. Ein Screenshot beweist, dass die Seite falsch aussah. Warum, sagt er nicht.

Sortiert danach, was Bugs tatsächlich löst:

Der fehlgeschlagene Request: Methode, URL, Status, Response-Body und eine Request- oder Trace-ID, falls vorhanden. Eine Request-ID macht aus einem clientseitigen Bericht eine Suche in den Server-Logs, und das ist der kürzeste Weg vom Bericht zur Ursache, den es gibt.
Der Console-Fehler mit Stack: zeigt auf eine Codezeile.
Eine Aufnahme: zeigt Timing und Reihenfolge, was Screenshots nicht können.
Ein Screenshot: zeigt den Endzustand.

Die meisten Vorlagen fragen nach dem vierten und erwähnen die ersten drei nie, weil die ersten drei DevTools voraussetzen, und wer einen Bug meldet, hat keine DevTools offen.

Und jetzt lösch das meiste davon

Geh die Vorlage noch einmal durch und sortiere die Felder danach, wer sie liefern kann.

Nur ein Mensch kann liefern: Zusammenfassung, Schritte zur Reproduktion, das Erwartete und den Teil „wer und wie oft“ der Auswirkung. Dafür braucht es eine Absicht. Keine Instrumentierung der Welt weiß, was jemand erreichen wollte oder zu sehen erwartete.

Eine Maschine kann liefern, und zwar besser: Umgebung, tatsächliches Verhalten und alle vier Arten von Belegen.

Bei jedem Feld der zweiten Gruppe verlangst du von einem Menschen eine Arbeit, die ein Skript besser machen könnte, und bezahlst dafür mit abgebrochenen Berichten.

Schau dir an, was „Umgebung“ wirklich verlangt. Browser und genaue Version: Die meisten finden das nicht. Version des Betriebssystems: genauso. Viewport-Größe: Die kennt niemand, und genau dieses Feld hätte den Layout-Bug erklärt. Seiten-URL: Eingefügt wird die URL der Seite, auf der man gerade ist, also dein Support-Formular. App-Version oder Build-Hash: absichtlich unsichtbar.

Sechs Angaben, jede trivial aus dem Browser auslesbar, und jede kostet eine Support-Runde, wenn ein Mensch sie liefern soll.

Für Belege gilt dasselbe Argument noch stärker. Du verlangst von einer Person ohne technischen Hintergrund, die DevTools zu öffnen, den Netzwerk-Tab zu finden, den Bug zu reproduzieren, unter zweihundert Requests den richtigen zu finden und seine Antwort zu kopieren. Das wird sie nicht tun. Und es ist eine Zeile Instrumentierung.

Wie das Formular aussehen sollte

Reduzier es auf das, was nur ein Mensch weiß:

## Was ist schiefgelaufen?
[Freitext]

## Was hast du erwartet?
[Freitext]

## Ist das schon einmal passiert?
( ) Zum ersten Mal  ( ) Manchmal  ( ) Jedes Mal

Drei Felder. Dreißig Sekunden. Gleichzeitig kommt der Bericht mit Browser, Betriebssystem, Viewport und URL an, mit der Console samt allem, was vor dem Öffnen des Formulars geloggt wurde, dem Netzwerk-Log mit Status und Timings, einem Session-Replay der letzten Minuten und den Klicks und Eingaben der Person in der richtigen Reihenfolge.

Um genau diesen Tausch geht es: Der Mensch schreibt den Satz, den nur er schreiben kann, und die Maschine hängt alles andere an.

Genau das macht BugDump. Ein Script-Tag setzt einen Button zum Melden auf die Seite, die Person schreibt, was schiefgelaufen ist, und der Bericht kommt mit bereits angehängter Telemetrie an, dazu ein annotierter Screenshot, den sie weichzeichnen kann, bevor er ihren Browser überhaupt verlässt. Der kostenlose Plan umfasst 500 Berichte pro Projekt.

Zwei Dinge, die du weiter von Hand machst

Automatisches Erfassen automatisiert nicht alles, und die Grenzen sollte man klar benennen.

Triage braucht weiterhin einen Menschen. Zwölf Berichte über denselben kaputten Checkout sollten eine Aufgabe mit zwölf Belegen werden, und nur ein Mensch erkennt, dass es derselbe Bug ist. Durch dieses Bündeln hören doppelte Berichte auf, Rauschen zu sein, und werden zu Daten: Zwölf Berichte aus fünf Browsern und zwei Betriebssystemen sind eine Matrix, und das Muster darin nennt meistens die Ursache. BugDump bildet das direkt ab: Berichte sind Belege, Aufgaben sind das, was du behebst, und viele Berichte hängen an einer Aufgabe.

Den Kreis schließen muss weiterhin ein Mensch. Ein Bericht, der im Nichts verschwindet, bringt jemandem bei, nichts mehr zu melden. Egal, welches Tool du benutzt: Wer etwas gemeldet hat, muss sehen, dass sich daran etwas bewegt. Gib den Leuten eine Statusseite oder schick ihnen eine Nachricht, wenn der Fix live ist. Ein öffentliches Portal, auf dem sie ihre Aufgabe von Bestätigt nach Fertig wandern sehen, ist die billigste Variante davon, die funktioniert.

Vorlagen stehen stellvertretend für das eigentliche Ziel: einen Bericht, mit dem das Entwicklungsteam ohne Rückfrage arbeiten kann. Bringt dich ein Formular dorthin, nimm das oben. Schafft Instrumentierung das ohne Formular, ist das klar besser. Die beste Vorlage für Fehlerberichte ist die, die niemand ausfüllen muss.