Bug-Report-Vorlage: Aufbau, Beispiel und Checkliste zum Übernehmen

Hier ist eine Bug-Report-Vorlage, die sich in Kundenprojekten bewährt hat – einmal ausführlich für Technik-Teams und QA, einmal kompakt für Melder ohne Technik-Hintergrund. Beide kannst du direkt übernehmen: als Vorlage im Wiki, als Formularfelder oder als Struktur für euer Meldeformular. Danach gehen wir jedes Feld durch und zeigen an einem ausgefüllten Beispiel, wie ein Report aussieht, mit dem die Entwicklung sofort arbeiten kann.

Die Vorlage zum Kopieren

Acht Felder, bewusst in dieser Reihenfolge – erst das Was, dann das Wie, dann die Umstände:

• Titel: Bereich plus Symptom in einem Satz – „Checkout: Bestellung bricht bei langer Lieferadresse ab“
• Ist-Verhalten: Was passiert – als Beobachtung, nicht als Vermutung
• Soll-Verhalten: Was stattdessen passieren müsste
• Schritte zum Nachstellen: nummeriert, ab einem eindeutigen Startpunkt (eingeloggt? welche Seite?)
• Umgebung: Browser mit Version, Betriebssystem, Gerät, Fenstergröße
• Häufigkeit: immer, manchmal (mit erkennbarem Muster) oder bisher einmalig
• Anhang: markierter Screenshot oder kurzes Video, dazu Fehlermeldungen im Wortlaut
• Wirkung aus Meldersicht: blockiert mich komplett / stört, aber es gibt einen Umweg / Kleinigkeit

Das ausgefüllte Beispiel

So sieht die Vorlage mit einem echten Fall aus – dem Klassiker, der nur bei bestimmten Daten auftritt:

• Titel: Checkout: Bestellung bricht bei langer Lieferadresse ab
• Ist: Nach Klick auf „Zahlungspflichtig bestellen“ erscheint eine leere weiße Seite. Die Bestellung taucht nicht im Kundenkonto auf, es kommt keine Bestätigungsmail.
• Soll: Bestätigungsseite mit Bestellnummer und Mailversand.
• Schritte: 1. Als Kunde einloggen, Artikel in den Warenkorb legen. 2. Zur Kasse gehen. 3. Als Straße „Bürgermeister-Wilhelm-Sedlmayr-Straße 128a, Hinterhaus links“ eingeben. 4. Zahlart Rechnung wählen, bestellen.
• Umgebung: Chrome 126, Windows 11, Desktop, Fenster 1440 × 900.
• Häufigkeit: Immer, sobald die Straße inklusive Zusatz länger als etwa 60 Zeichen ist. Mit kurzer Adresse klappt alles.
• Anhang: Screenshot der leeren Seite, Konsole zeigt zwei rote Fehlermeldungen (im Screenshot markiert).
• Wirkung: Blockiert – Kunden mit langen Adressen können nicht bestellen.

Woran man die Qualität erkennt: Der Melder hat den Grenzwert eingekreist („länger als etwa 60 Zeichen“), Beobachtung und Vermutung getrennt und den Gegentest gemacht („mit kurzer Adresse klappt alles“). Diese drei Handgriffe verwandeln eine Stunde Rätselraten in fünf Minuten Nachstellen – und genau dafür lohnt sich die Vorlage.

Die Kurzfassung für Kunden und Kollegen

Von jemandem ohne Technik-Hintergrund acht Felder zu verlangen, ist der sichere Weg zu gar keinen Meldungen. Für Kunden, Redaktion oder Vertrieb reichen drei Fragen:

• Auf welcher Seite warst du?
• Was wolltest du tun, und was ist stattdessen passiert?
• Magst du einen Screenshot mitschicken und die Stelle markieren?

Mehr braucht es nicht – den technischen Rest sollte das Werkzeug beisteuern. Ein Feedback-Widget erfasst Browser, Betriebssystem, Fenstergröße und die Fehler aus der Browser-Konsole automatisch und hängt sie an die Meldung. Der Melder beantwortet drei Fragen, das Team bekommt trotzdem einen vollständigen Report.

Die Felder im Detail

Titel: Bereich plus Symptom

Der Titel wird häufiger gelesen als der Rest des Reports zusammen – in Listen, in Suchergebnissen, in der Triage. „Fehler!!“ und „Seite kaputt“ sind darum verlorene Titel. Das Muster Bereich plus Symptom („Suche: Umlaute liefern keine Treffer“) macht den Report sortierbar und beim Duplikat-Check auffindbar.

Ist und Soll: Beobachtung statt Diagnose

Ins Ist-Feld gehört, was zu sehen war – nicht, was der Melder für die Ursache hält. „Vermutlich ein CSS-Problem“ ist gut gemeint, lenkt aber die Fehlersuche in eine Richtung, die falsch sein kann. Wer eine Vermutung hat, stellt sie ans Ende, klar als solche markiert. Das Soll wirkt oft überflüssig, ist es aber nicht: Bei „der Filter zeigt archivierte Einträge“ weiß ohne Soll-Angabe niemand, ob das ein Bug oder ein Missverständnis über die Funktion ist.

Schritte: der Startpunkt entscheidet

Die meisten unbrauchbaren Reproduktionsschritte scheitern am ersten Schritt, nicht am letzten: Es fehlt der Zustand, in dem es losging. Eingeloggt oder nicht? Leerer Warenkorb oder voller? Erster Besuch oder wiederkehrend? Ein eindeutiger Startpunkt („ausgeloggt auf der Startseite beginnen“) macht die Schritte für jeden nachvollziehbar – auch für die Person, die den Fehler in drei Wochen prüft.

Umgebung: die unterschätzte Hälfte

Gerade bei Web-Projekten entscheidet die Umgebung darüber, ob sich ein Fehler überhaupt zeigt: Er tritt in Safari auf, aber nicht in Chrome; auf dem Handy, aber nicht am Desktop; bei schmalem Fenster, aber nicht im Vollbild. Ohne diese Angaben testet die Entwicklung in ihrer eigenen Umgebung, findet nichts – und der Report endet als „kann ich nicht nachstellen“.

Eine Meldung, ein Fehler

Wer beim Testen drei Dinge findet, schreibt drei Reports – auch wenn es sich nach Aufwand anfühlt. Der Grund ist praktisch: Drei Fehler in einem Report lassen sich weder getrennt zuweisen noch getrennt schließen. Fehler zwei ist behoben, Fehler drei nicht – welchen Status bekommt der Report? Im Zweifel bleibt er ewig offen, und der erledigte Teil versteckt den unerledigten. Drei kleine Reports sind schneller geschrieben als ein Sammelreport aufgedröselt.

Wie schlimm, wie dringend?

Große QA-Organisationen trennen Severity (wie schwer wiegt der Fehler technisch) und Priorität (wie schnell muss er weg). Für kleine Teams reicht die Wirkungsangabe des Melders aus der Vorlage – blockiert, stört, Kleinigkeit – als Rohstoff. Die eigentliche Priorität vergibt danach das Team in der Triage, gemessen an der Wirkung auf alle Nutzer, nicht nur auf den Melder. Wie dieser Weg vom Report bis zum Fix weitergeht, beschreibt der Beitrag zum Bug-Tracking.

Checkliste vor dem Absenden

• Nennt der Titel Bereich und Symptom?
• Sind Ist und Soll als Beobachtung formuliert, Vermutungen klar markiert?
• Beginnen die Schritte an einem eindeutigen Startpunkt?
• Ist der Screenshot markiert, die Fehlermeldung im Wortlaut dabei?
• Stehen Browser, System und Gerät im Report – oder liefert sie das Widget mit?
• Beschreibt der Report genau einen Fehler?
• Kurz gesucht: Ist derselbe Fehler vielleicht schon gemeldet?

Die Vorlage überflüssig machen

Die ehrlichste Pointe zum Schluss: Der beste Bug-Report ist der, den niemand von Hand ausfüllen muss. Beim Live-Issue-Widget markiert der Melder die Stelle direkt im Screenshot – mit Pfeil, Rechteck oder Stift –, und Browser, Betriebssystem, Fenstergröße und Konsolen-Fehler kommen automatisch mit. Die Meldung landet im Eingang, wo sie triagiert wird und zur Aufgabe mit Priorität und Zuständigkeit wird. Die Vorlage aus diesem Beitrag bleibt trotzdem nützlich: für alles, was nicht über die Website hereinkommt – und als gemeinsames Verständnis davon, was eine gute Meldung ausmacht.