Kurz gesagt
Ein brauchbarer Bug-Report enthält sechs Angaben: URL, betroffenes Element, Schritte zur Reproduktion, erwartetes Verhalten, tatsächliches Verhalten und Umgebung (Browser, System, Auflösung).
Die Vorlage
Kopiere diese Felder in dein Feedback-Tool oder nutze ein Tool, das die Umgebung automatisch erfasst.
- URL: wo tritt es auf?
- Element: welches Element genau?
- Schritte: 1. … 2. … 3. …
- Erwartet: was sollte passieren?
- Tatsächlich: was passiert stattdessen?
- Umgebung: Browser, Betriebssystem, Auflösung
Ausgefülltes Beispiel
So sieht die Vorlage in der Praxis aus, statt leer zu bleiben:
- URL: /warenkorb
- Element: Button „Zur Kasse“
- Schritte: 1. Produkt in den Warenkorb legen 2. Warenkorb öffnen 3. Auf „Zur Kasse“ klicken
- Erwartet: Weiterleitung zur Checkout-Seite
- Tatsächlich: Seite lädt neu und bleibt im Warenkorb
- Umgebung: Safari 17, iOS 17.4, iPhone 13
Warum die Umgebung entscheidend ist
Ein großer Teil der Meldungen ist umgebungsabhängig. Ohne Browser- und Auflösungsangabe testet dein Team am falschen Ort und meldet den Fehler als nicht reproduzierbar zurück.
Automatisch statt manuell
Die Felder Umgebung, URL und Element muss niemand tippen. nootiz erfasst sie beim Erstellen der Notiz automatisch, was die Vorlage auf drei freie Felder reduziert: Schritte, Erwartet, Tatsächlich.
Wie detailliert müssen Reproduktionsschritte sein?
So detailliert, dass eine Person, die die Seite noch nie gesehen hat, den Fehler nachstellen kann. Ein Schritt wie „Formular ausfüllen“ reicht nicht – nenne die konkreten Eingaben.
Schweregrad einordnen
Ergänze die Vorlage um eine grobe Einstufung, damit dein Team weiß, was zuerst dran ist:
- Blocker: Kernfunktion (z. B. Kauf, Login) funktioniert nicht
- Hoch: Funktion eingeschränkt, Umgehung möglich
- Niedrig: kosmetischer Fehler ohne Funktionsverlust
Ein Bug pro Meldung
Auch wenn zwei Fehler zusammenhängend erscheinen: eine Meldung pro Fehler erlaubt getrennte Priorisierung und getrennten Status.
Typische Fehler beim Ausfüllen der Vorlage
Diese Punkte tauchen in der Praxis am häufigsten auf und machen einen Report unbrauchbar:
- Erwartetes Verhalten fehlt komplett
- Schritte sind zu allgemein formuliert
- Umgebung wird nachträglich erfragt statt sofort erfasst
- Mehrere Fehler landen in einer Meldung
Screenshots vs. Live-Kontext
Ein Screenshot zeigt einen Zeitpunkt, aber nicht die Interaktion davor. Eine Notiz direkt am Element auf der laufenden Seite zeigt zusätzlich Zustand und Umgebung im selben Moment.
Vom Report zur Aufgabe
Ein Bug-Report ist erst dann nützlich, wenn er im Tool des Entwicklungsteams landet. Notizen, die sich an Jira, GitHub, Trello oder Asana übergeben lassen, sparen den manuellen Abtippschritt.
Wer füllt welches Feld aus?
Melder liefern URL, Element, Schritte, Erwartet und Tatsächlich. Umgebung sollte automatisch erfasst werden, nicht manuell. Schweregrad legt idealerweise die Entwicklung oder QA fest, da sie den technischen Kontext kennt – der Melder markiert nur, wie stark die eigene Arbeit blockiert ist.
Was tun bei widersprüchlichen Angaben in der Vorlage?
Wenn „Erwartet“ und „Tatsächlich“ inhaltlich gleich klingen, ist das Feld falsch verstanden worden. Frage konkret nach: „Was hättest du stattdessen gesehen?“ – oft klärt sich der Widerspruch, sobald jemand das Zielverhalten explizit benennt.
Die Vorlage im verteilten Team nutzen
Bei asynchroner Zusammenarbeit muss die Vorlage ohne Rückfrage auslangen. Ergänze deshalb immer einen Zeitstempel und, falls relevant, die Zeitzone der meldenden Person, damit „gerade eben aufgetreten“ nachvollziehbar bleibt.
Eine Meldung abschließen
Markiere eine Meldung erst als erledigt, wenn der Fix im entsprechenden Deployment live ist und die meldende Person bestätigt hat, dass das Verhalten jetzt dem erwarteten entspricht. Ein Status „in Bearbeitung“ ohne Rückmeldetermin bleibt sonst unbegrenzt offen.
Die Vorlage ohne Tool nutzen
Die sechs Felder funktionieren genauso in einer geteilten Tabelle oder einem einfachen Dokument. Der Unterschied zu einem spezialisierten Tool liegt allein darin, dass Umgebung und Screenshot dort manuell nachgetragen werden müssen.
Häufige Fragen
Brauche ich ein Ticketsystem für Bug-Reports?
Nicht zwingend. Für Website-Projekte genügt eine Notizliste mit Status und Zuweisung.
Was gehört nicht in einen Bug-Report?
Vermutungen zur Ursache im Code. Beschreibe das beobachtete Verhalten, die Ursachensuche ist Aufgabe des Entwicklungsteams.
Wie melde ich Fehler, die nur manchmal auftreten?
Notiere trotzdem alle bekannten Bedingungen und markiere den Report als „tritt unregelmäßig auf“ statt ihn wegzulassen.
Reicht eine Videoaufnahme statt der Vorlage?
Ein Video zeigt das Verhalten, ersetzt aber nicht die Angaben zu Umgebung und erwartetem Ergebnis.
Wer sollte Bug-Reports erstellen dürfen?
Jede Person, die die Website nutzt – auch nicht-technische Kollegen und Kunden, solange die Vorlage einfach genug ist.
Wie geht man mit doppelt gemeldeten Bugs um?
Zusammenführen und auf die ausführlichere Meldung verweisen, statt beide parallel zu bearbeiten.
Muss ich die Konsole/Entwicklertools auslesen?
Hilfreich, aber nicht Pflicht. Wenn vorhanden, Fehlermeldung aus der Konsole als zusätzliches Feld ergänzen.
Sollte die Vorlage für jedes Projekt gleich aussehen?
Die sechs Kernfelder ja, projektspezifische Ergänzungen wie Kontoart oder Sprache können dazukommen.