Die Vorlage direkt verwenden
Bug-Report
1. Seite (URL)
Die exakte Adresse, auf der der Fehler auftritt – kopiert, nicht beschrieben.
2. Element
Welches Element auf der Seite: „der Absenden-Button des Kontaktformulars", nicht „der Button".
3. Umgebung
Gerät, Browser + Version, Betriebssystem. Das Feld, das die meisten Meldungen auslassen – und das über die Nachstellbarkeit entscheidet.
4. Schritte zum Nachstellen
Nummeriert, ab frischem Seitenaufruf: 1. Öffne… 2. Klicke… 3. Tippe…
5. Erwartetes Verhalten
Was hätte passieren sollen – ein Satz.
6. Tatsächliches Verhalten
Was stattdessen passiert ist – inklusive der exakten Fehlermeldung, falls vorhanden.
7. Beleg
Screenshot oder Bildschirmaufnahme. Am besten: eine Markierung auf der Live-Seite, die alles oben automatisch mitbringt.
8. Schweregrad
Blocker (Kern-Ablauf unbenutzbar) · Schwer (kaputt, Umweg existiert) · Leicht (falsch, kein Schaden) · Kosmetisch (Feinschliff)
Eine gute Meldung vs. eine typische
Typisch: „Das Kontaktformular geht nicht." – Welche Seite? Welcher Browser? Geht nicht, wie? Drei Rückfragen, bevor irgendjemand anfangen kann.
Gut: „Auf /kontakt passiert nach dem Tippen auf Absenden (iPhone 15, Safari 18, iOS 18) nichts. Schritte: Seite öffnen, alle Felder ausfüllen, Absenden tippen. Erwartet: Erfolgsmeldung. Tatsächlich: nichts, keine Fehlermeldung. Screenshot anbei." – Beim ersten Versuch nachstellbar.
Oder das Formular ganz überspringen
In bepeq pinnt die meldende Person den Fehler auf die Live-Seite – URL, Element, Gerät, Browser und Betriebssystem werden automatisch erfasst. Bei vager Beschreibung fragt der Pilot nach. Die Meldung kommt vollständig an, ohne dass jemand eine Vorlage ausfüllt.
bepeq kostenlos testenKunde
„Der Bereich oben gefällt mir nicht so."
✦ bepeq Pilot fragt nach
Was genau stört: Farben, Bild oder Text?
Hero-Bild heller, Headline kontrastreicher.
umsetzbarPassende Vorlagen und Leitfäden
Über diese Vorlage
Erstellt von David Malewski, Gründer von bepeq (DAMA Solutions GmbH), auf Basis echter QS-Runden in Webprojekten. Frei verwendbar und anpassbar. Zuletzt aktualisiert am 13. Juli 2026.
Häufige Fragen zu Bug-Reports
Was gehört in einen Bug-Report?
Sieben Felder: die Seiten-URL, das exakte Element, die Umgebung (Gerät, Browser, Betriebssystem), nummerierte Schritte zum Nachstellen, das erwartete Verhalten, das tatsächliche Verhalten und ein Beleg (Screenshot, Aufnahme oder eine Markierung auf der Live-Seite). Dazu ein Schweregrad, damit die Reihenfolge der Behebung klar ist.
Warum braucht ein Bug-Report die Umgebungs-Angaben?
Weil die meisten Frontend-Fehler umgebungsspezifisch sind: Sie existieren in Safari, aber nicht in Chrome, auf dem 375-Pixel-Handy, aber nicht am Büro-Monitor. Eine Meldung ohne Gerät, Browser und Betriebssystem macht aus Beheben ein Raten – und kostet pro Bug eine komplette Rückfrage-Runde.
Wie bekommt man brauchbare Bug-Reports von Kunden?
Schick ihnen kein Formular – gib ihnen ein Werkzeug, das das Formular für sie ausfüllt. Wenn der Kunde seine Anmerkung direkt auf der Live-Seite pinnt, werden URL, Element-Position, Gerät, Browser und Betriebssystem automatisch erfasst. Der Kunde schreibt einen Satz; die Meldung kommt trotzdem vollständig an.
Welche Schweregrade sind für Webprojekte sinnvoll?
Vier reichen: Blocker (Seite oder Kern-Ablauf unbenutzbar), Schwer (Funktion kaputt, Umweg existiert), Leicht (falsches Verhalten ohne echten Schaden), Kosmetisch (Feinschliff). Mehr Stufen erzeugen Debatten statt Klarheit – der Zweck ist die Reihenfolge der Behebung.
Ein Bug pro Meldung oder eine Sammelliste?
Immer ein Bug pro Meldung. Sammellisten („10 Dinge, die mir aufgefallen sind") lassen sich nicht einzeln zuweisen, verfolgen oder schließen – Punkt fünf geht im Erledigt-Gefühl der anderen neun verloren. Werkzeuge, die jeden Fund einzeln pinnen, erzwingen das automatisch.