Fehlerbericht schreiben: Vorlage für Website-Betreiber
Kurz gesagt: Ein guter Fehlerbericht enthält einen kurzen Titel, die genaue Adresse, nummerierte Schritte zum Nachstellen, erwartetes und tatsächliches Ergebnis, Gerät und Browser mit Version, Zeitpunkt und einen Screenshot oder ein kurzes Video. Pro Bericht nur ein Fehler. So kann der Entwickler das Problem nachstellen, statt es erst suchen zu müssen.
„Geht nicht“ ist als Fehlermeldung ehrlich gemeint und ziemlich teuer. Bevor jemand etwas reparieren kann, muss er den Fehler selbst sehen. Wenn er dafür eine halbe Stunde lang ausprobiert, welche Seite, welches Gerät und welcher Klick gemeint war, zahlst du diese halbe Stunde mit.
Ein sauberer Fehlerbericht ist deshalb kein Formalkram. Er ist der billigste Teil der Reparatur.
Was in einen Fehlerbericht gehört
Die Bugzilla-Richtlinien von Mozilla nennen die Schritte zum Nachstellen den wichtigsten Teil eines Berichts. Dazu kommen ein eindeutiger Titel, das erwartete und das tatsächliche Ergebnis sowie Angaben zu Version und System. Für die Website eines kleinen Unternehmens lässt sich das gut übersetzen:
- Titel: etwa zehn Wörter, die den Fehler beschreiben, nicht die Lösung. Mozilla empfiehlt unter 60 Zeichen.
- Adresse: die vollständige URL, nicht „auf der Produktseite“.
- Schritte: nummeriert, so dass ein Fremder sie nachklicken kann.
- Erwartet: was passieren sollte.
- Tatsächlich: was stattdessen passiert, inklusive Fehlermeldung im Wortlaut.
- Umgebung: Gerät mit Betriebssystem sowie der Browser samt Version.
- Häufigkeit: immer, manchmal, einmal.
- Zeitpunkt: Datum und Uhrzeit, möglichst auf die Minute.
- Belege: Screenshot oder Bildschirmvideo.
Mehr braucht es nicht. Wer zusätzlich festhält, seit wann der Fehler auftritt und ob vorher etwas geändert wurde, spart dem Entwickler die erste Rückfrage.
Vorlage zum Kopieren
Titel: [Was passiert, wo] – z. B. „Warenkorb leert sich nach Login auf Mobilgeräten“
Adresse: https://...
Schritte zum Nachstellen:
1.
2.
3.
Erwartetes Ergebnis:
Tatsächliches Ergebnis:
(Fehlermeldung wörtlich abschreiben oder Screenshot)
Umgebung:
Gerät / Betriebssystem:
Browser und Version:
Eingeloggt als: (Rolle, nicht das Passwort)
Häufigkeit: immer / manchmal (x von 10) / einmal
Zeitpunkt: TT.MM.JJJJ, hh:mm Uhr
Seit wann / was wurde vorher geändert:
Anhänge: Screenshot, Video, Konsolen-Ausgabe
Dringlichkeit: blockiert Verkäufe / stört / kosmetisch
Die Zeile zur Dringlichkeit ist für den Entwickler die wichtigste Planungsinformation. „Blockiert Verkäufe“ heißt: heute noch. „Kosmetisch“ heißt: beim nächsten Termin mit erledigen.
Beispiel: vorher und nachher
Eine typische Mail lautet: „Hallo, bei uns funktioniert der Checkout nicht, Kunden beschweren sich. Bitte dringend ansehen.“ Damit fängt die Suche an. Welcher Zahlungsweg? Alle Kunden oder nur manche? Seit wann?
Derselbe Fehler, mit der Vorlage beschrieben:
- Titel: PayPal-Zahlung bricht auf iPhone mit Fehlermeldung ab
- Adresse: https://beispiel-shop.de/kasse/
- Schritte: 1. Beliebiges Produkt in den Warenkorb. 2. Zur Kasse, als Gast. 3. Zahlungsart PayPal wählen. 4. „Jetzt kaufen“ tippen.
- Erwartet: Weiterleitung zu PayPal.
- Tatsächlich: Hinweis „Es ist ein Fehler aufgetreten“, Bestellung wird nicht angelegt.
- Umgebung: iPhone 13, iOS 18, Safari. Am Desktop mit Firefox funktioniert es.
- Häufigkeit: fünf von fünf Versuchen auf dem iPhone.
- Zeitpunkt: 14.10., 09:42 Uhr, Video angehängt.
Mit dieser Fassung weiß der Entwickler, dass er mobil und mit Safari testen muss, und kann im Log nach Einträgen um 9:42 Uhr suchen. Aus einer offenen Suche ist eine gezielte geworden.
| Kriterium | „Checkout geht nicht“ | Bericht mit Vorlage |
|---|---|---|
| Betroffene Seite | ||
| Schritte zum Nachstellen | ||
| Gerät und Browser | ||
| Zeitpunkt für die Log-Suche | ||
| Einschätzung der Dringlichkeit | teilweise | |
| Aufwand vorab schätzbar | teilweise |
So findest du Browser-Version, Video und Konsolenfehler
Die technischen Angaben schrecken viele ab. Sie sind in zwei Minuten erledigt.
Die Browser-Version steht in Chrome und Edge unter Einstellungen, Abschnitt „Über Chrome“ beziehungsweise „Info zu Microsoft Edge“. In Firefox findest du sie im Menü unter Hilfe, „Über Firefox“, in Safari auf dem Mac unter Safari, „Über Safari“. Auf dem iPhone reicht die iOS-Version aus den Einstellungen, weil Safari daran gekoppelt ist.
Ein Bildschirmvideo sagt oft mehr als jede Beschreibung. Auf dem Mac öffnet Shift + Cmd + 5 die Bildschirmaufnahme. Unter Windows 11 kann das Snipping Tool auch Videos aufnehmen. iPhone und Android haben eine Bildschirmaufnahme im Kontrollzentrum beziehungsweise in den Schnelleinstellungen. Zwanzig Sekunden reichen.
Die Konsole ist für Fehler auf Webseiten Gold wert. In Chrome und Edge öffnest du sie mit F12 oder Strg + Shift + J, auf dem Mac mit Cmd + Option + J. Rote Zeilen sind Fehler. Mach einen Screenshot davon, auch wenn dir der Inhalt nichts sagt.
Bevor du den Bericht abschickst, lohnt ein Test im privaten Fenster. Funktioniert es dort, liegt das Problem wahrscheinlich am Cache, an Cookies oder an einer Browser-Erweiterung. Das gehört dann ebenfalls in den Bericht.
Wie dringend ist der Fehler wirklich?
Fast jeder Fehler fühlt sich im ersten Moment dringend an. Für die Planung hilft es, zwei Dinge auseinanderzuhalten: wie schwer der Fehler ist und wie schnell er weg sein muss. Fachleute sprechen von Schweregrad und Priorität. Ein abgestürzter Checkout ist schwer und eilig. Ein falsches Datum im Impressum ist leicht, kann aber vor einer Abmahnung trotzdem eilig werden.
Für kleine Aufträge reichen drei Stufen, und die gehören als eigene Zeile in jeden Bericht:
| Stufe | Bedeutung | Erwartete Reaktion |
|---|---|---|
| blockiert | Umsatz, Anfragen oder Logins fallen aus | am selben Tag, notfalls mit Aufpreis |
| stört | Funktion geht, aber umständlich oder fehlerhaft | innerhalb weniger Arbeitstage |
| kosmetisch | Darstellung, Tippfehler, Abstände | beim nächsten geplanten Termin |
Wer jede Meldung als „blockiert“ einstuft, verliert schnell Glaubwürdigkeit. Und Eilaufträge außerhalb der normalen Planung können einen Zuschlag kosten, das steht oft in den Konditionen. Ehrlich einstufen spart also auch Geld. Ob dein Fehler ohne Aufpreis in die normale Woche passt, klärst du am besten vor dem Auftrag, zusammen mit dem Stundensatz.
Ein Fehler pro Bericht
Mozilla schreibt es ausdrücklich: ein Bug pro Meldung. Für kleine Aufträge gilt das genauso. Fünf Fehler in einer Mail führen dazu, dass vier erledigt und einer vergessen wird, und niemand weiß später, welcher.
Getrennte Berichte haben noch einen Vorteil: Jeder lässt sich einzeln schätzen. Du kannst entscheiden, dass der Abbruch im Checkout sofort behoben wird und der verrutschte Footer bis zum nächsten Wartungstermin wartet. Wie viel solche kleinen Eingriffe kosten, haben wir unter Website-Änderung: Kosten aufgeschlüsselt.
Achte darauf, was du anhängst. Screenshots aus dem Backend zeigen manchmal Kundendaten oder Zugangsdaten. Schwärzen kostet zehn Sekunden. Wenn der Entwickler zum Nachstellen einen Login braucht, schick ihn nicht im Bericht mit, sondern über einen sicheren Weg für Zugangsdaten.
Wann ein Fehlerbericht zum Auftrag wird
Ein Fehlerbericht beschreibt, was kaputt ist. Er sagt noch nicht, was nach der Reparatur gelten soll. Bei einfachen Fällen ist das offensichtlich: Der Checkout soll wieder funktionieren. Bei allem, was darüber hinausgeht, hilft ein Satz, der festhält, woran du die Behebung prüfst. Wie man solche Sätze formuliert, zeigen die Akzeptanzkriterien mit Beispielen.
Wenn du merkst, dass sich die Berichte häufen, dieselben Bereiche immer wieder brechen und jeder Fix einen neuen Fehler nach sich zieht, ist das ein Zeichen für ein strukturelles Problem. Dann ist ein fester Partner für Entwicklung und Betrieb oft günstiger als die nächste Runde Einzelaufträge.
Für den aktuellen Fehler: Kopier die Vorlage, nimm ein 20-Sekunden-Video auf und schick beides zusammen ab. Wer gründlicher werden will, findet in den Bugzilla-Richtlinien von Mozilla noch Hinweise für Abstürze und Performance-Probleme.
Häufige Fragen
Was ist der Unterschied zwischen Schweregrad und Priorität?
Der Schweregrad beschreibt, wie stark der Fehler das System beeinträchtigt. Die Priorität sagt, wie dringend er behoben werden soll. Ein Tippfehler auf der Startseite hat einen geringen Schweregrad, kann aber vor einer Messe hohe Priorität haben.
Soll ich vermuten, woran der Fehler liegt?
Gern, aber getrennt von den Beobachtungen und als Vermutung gekennzeichnet. Ein Hinweis wie „seit dem Plugin-Update am Dienstag“ ist wertvoll. „Bestimmt der Server“ ohne Grund lenkt eher ab.
Was mache ich, wenn der Fehler nur manchmal auftritt?
Schreib auf, wie oft er auftritt, etwa drei von zehn Versuchen, und notiere bei jedem Auftreten Uhrzeit, Gerät und was du unmittelbar davor getan hast. Mit Uhrzeiten kann der Entwickler in den Server-Logs nach dem passenden Eintrag suchen.
Darf ich mehrere Fehler in eine Mail schreiben?
Besser nicht. Ein Bericht pro Fehler lässt sich einzeln schätzen, beheben und abhaken. Wenn du trotzdem eine Sammelmail schickst, nummeriere die Fehler und gib jedem eigene Schritte.