Die Bugreport-Vorlage, die kein Reviewer ablehnt

Was ist eine Bugreport-Vorlage?

Eine Bugreport-Vorlage nennt jedes Feld, das ein Ticket braucht, bevor ein Entwickler daran arbeiten kann, vom Titel bis zur Umgebungszeile, sodass nach dem Einreichen nichts mehr nachgetragen werden muss. Jedes Feld beantwortet eine Frage, die ein Reviewer sonst in einem Kommentar-Thread stellen müsste. Fülle jedes Feld vor dem Absenden aus, und behandle ein leeres Feld als Grund, warum das Ticket zurückgeschickt wird.

Warum gibt es das Titel-Feld und was macht einen guten Titel aus?

Das Titel-Feld existiert, damit ein Reviewer erkennt, was kaputt ist, ohne das Ticket zu öffnen, was entscheidet, ob es beim nächsten Triage-Durchgang aufgegriffen oder unter fünfzig anderen begraben wird. Ein brauchbarer Titel nennt die Aktion und den Fehler zusammen, etwa "Eine Geschenkkarte beim Checkout einzulösen zeigt eine leere Seite statt eines Fehlers", nicht eine Stimmung wie "Checkout ist kaputt". Schreib den Titel zuletzt, nachdem die Schritte und das tatsächliche Ergebnis klar sind, damit er den echten Fehler statt einer Vermutung benennt.

Warum gibt es das Feld für Schritte zur Reproduktion?

Das Feld für Schritte zur Reproduktion existiert, damit eine zweite Person denselben Fehler auslösen kann, ohne den Melder sonst noch etwas zu fragen, wodurch aus einer einmaligen Beobachtung ein wiederholbarer Testfall wird. Nummerierte Aktionen ab einem genannten Startpunkt trennen einen Report, mit dem ein Entwickler arbeiten kann, von einem Report, der ein Folgemeeting braucht. Schritte zur Reproduktion zeigt, wie ein vollständiger Satz Schritte aussieht und warum eine fehlende Voraussetzung der häufigste Grund ist, warum sie scheitern.

Warum braucht Schweregrad ein eigenes Feld, getrennt von Priorität?

Schweregrad braucht ein eigenes Feld, weil er den technischen Schaden misst, während Priorität misst, wie schnell jemand den Fehler beheben muss, und die beiden Antworten stimmen selten überein. Ein Zahlungsfehler, der an einem Wochenende ein einzelnes Konto trifft, ist schwerwiegend, aber heute Nacht nicht dringend; ein Tippfehler auf der Startseite ist geringfügig, aber vor einem Launch dringend. Schweregrad vs. Priorität schlüsselt auf, wie jemand in der Triage beide Werte vergibt, ohne dass eine Zahl in die andere hineinwirkt.

Schweregrad und Priorität ziehen in unterschiedliche Richtungen

Schwerwiegend, aber nicht dringend

• Zahlungsfehler betrifft ein Konto
• Tritt am Wochenende auf

Dringend, aber nicht schwerwiegend

• Tippfehler auf der Startseite
• Muss vor einem Launch behoben werden

Was gehört in das Umgebungsfeld?

Das Umgebungsfeld nennt Browser und Version, Betriebssystem, Bildschirmgröße und ob der Fehler in Produktion, Staging oder einem lokalen Build auftrat, weil dieselbe Klickfolge sich bei jedem einzelnen davon anders verhalten kann. Ein Reviewer ohne dieses Feld kann nicht erkennen, ob ein Bug universell ist oder an ein einzelnes Setup gebunden, was bedeutet, dass er nicht einmal abschätzen kann, wie viele Nutzer er betrifft. Kopiere die genaue Versionsangabe von der About-Seite des Browsers statt einer Vermutung wie "neuester Chrome".

Was gehört in die Felder für erwartetes Ergebnis und tatsächliches Ergebnis?

Das Feld für das erwartete Ergebnis nennt, was die Oberfläche zeigen sollte, und das Feld für das tatsächliche Ergebnis nennt genau, was stattdessen erschien, jeweils als eine konkrete Zeile, nicht als gemeinsamer Absatz darüber, wie sich der Bug angefühlt hat. "Erwartet wurde die Meldung 'Ungültiger Code', erschienen ist eine leere weiße Seite ohne Konsolenausgabe" gibt einem Entwickler etwas zum Abgleichen; "Checkout funktioniert nicht" nicht. Schreib beide Zeilen, bevor du den Titel schreibst, denn die Abweichung zwischen ihnen ist das, was der Titel benennen muss.

Feld	Welche Frage es beantwortet	Was ein Reviewer ablehnt, wenn es fehlt
Titel	Was ist kaputt, in einer Zeile	Ein vager oder stimmungsbasierter Titel ohne benannten Fehler
Voraussetzungen	Welcher Zustand vor Schritt eins bestand	Kontotyp, vorhandene Daten oder vorherige Aktionen fehlen
Schritte zur Reproduktion	Was in welcher Reihenfolge geklickt, eingegeben oder abgeschickt wird	Schritte, die eine Aktion auslassen oder nicht nummeriert sind
Erwartetes Ergebnis	Was hätte passieren sollen	Ein fehlendes oder vages erwartetes Ergebnis
Tatsächliches Ergebnis	Was stattdessen passiert ist	"Es ist kaputt" statt des genauen Fehlers oder Bildschirms
Schweregrad	Wie viel technischen Schaden der Bug verursacht	Schweregrad als Ersatz für Dringlichkeit verwendet
Priorität	Wie schnell der Bug behoben werden muss	Priorität ohne genannten Schweregrad zur Begründung festgelegt
Umgebung	Browser, Betriebssystem, Bildschirmgröße und Build-Stufe	"Neuester Chrome" statt einer genauen Versionsangabe

Was lässt einen Reviewer eine Einreichung rundweg ablehnen?

Ein Reviewer lehnt eine Einreichung rundweg ab, wenn eines der acht Felder oben leer, vage ist oder die falsche Frage beantwortet, denn wer die Triage macht, kann Schweregrad und Priorität nicht für einen Report vergeben, den er sich nicht vorstellen kann. Die häufigste einzelne Ursache ist eine fehlende Voraussetzung: Die Schritte wirken vollständig, aber niemand nennt den Kontostatus oder die vorhandenen Daten, die die Schritte voraussetzen. Die zweithäufigste Ursache ist, erwartetes und tatsächliches Ergebnis in einem Satz zu vermischen, was genau die Abweichung verbirgt, die eine Behebung schließen muss.

Wie füllt Session Replay eine Bugreport-Vorlage automatisch aus?

Session Replay füllt eine Bugreport-Vorlage automatisch aus, weil die Aufzeichnung bereits die Voraussetzungen, die nummerierten Aktionen und die Umgebung enthält, die ein manueller Report sonst von Hand beschreiben müsste. Flowsery hängt Replay, Schritte zur Reproduktion und Umgebungsdetails an jedes Issue an, sobald es in Slack, Linear oder Jira landet, sodass ein Melder nur noch den Schweregrad bestätigen muss, statt Felder neu einzutippen, die die Aufzeichnung bereits beantwortet. Derselbe Session-Replay-Bugreport zeigt einem Entwickler den genauen Klick, der den Fehler ausgelöst hat, was das Feld für das tatsächliche Ergebnis füllt, ohne dass jemand eine Beschreibung dafür schreibt.

Eine Bugreport-Vorlage der Reihe nach ausfüllen

1

Voraussetzungen nennen. Kontostatus, vorhandene Daten und alle vorherigen Aktionen vor Schritt eins.

2

Schritte zur Reproduktion nummerieren. Ein Klick, Tap oder eine Eingabe pro Zeile, in der ausgeführten Reihenfolge.

3

Erwartetes und tatsächliches Ergebnis als zwei Zeilen schreiben. Nicht ein Absatz darüber, wie sich der Bug angefühlt hat.

4

Schweregrad, dann Priorität bewerten. Verursachter Schaden, dann wie schnell er behoben werden muss.

5

Umgebung festhalten. Browser, Betriebssystem, Bildschirmgröße und Produktion, Staging oder lokal.

Häufig gestellte Fragen

Welche Felder braucht eine minimal brauchbare Bugreport-Vorlage?

Eine minimal brauchbare Vorlage braucht einen Titel, Voraussetzungen, nummerierte Schritte zur Reproduktion, erwartetes Ergebnis, tatsächliches Ergebnis, Schweregrad, Priorität und Umgebung. Lassen Sie eines dieser acht Felder weg, muss ein Reviewer vor der Triage eine Rückfrage stellen, genau die Verzögerung, die eine Vorlage beseitigen soll.

Können sich Schweregrad und Priorität ein Feld in einer Bugreport-Vorlage teilen?

Schweregrad und Priorität sollten sich kein Feld teilen, weil ein Bug schwerwiegend sein kann, ohne dringend zu sein, etwa ein Zahlungsfehler, der an einem Wochenende ein einzelnes Konto trifft, oder dringend sein kann, ohne schwerwiegend zu sein, etwa ein Tippfehler auf der Startseite vor einem Launch. Werden sie in einem Feld zusammengelegt, muss der Melder raten, welche Antwort die Zahl eigentlich darstellt.

Warum lehnen Reviewer Reports ab, die Schritte, aber keine Voraussetzungen haben?

Reviewer lehnen Reports mit Schritten, aber ohne Voraussetzungen ab, weil dieselbe Klickfolge je nach Kontostatus, vorhandenen Daten oder vorherigen Aktionen vor Schritt eins unterschiedliche Ergebnisse liefert. Ohne einen genannten Startpunkt muss ein Entwickler die Voraussetzung erst rekonstruieren, bevor er die aufgelisteten Schritte überhaupt versucht.

Was ist der Unterschied zwischen dem Umgebungsfeld und dem Feld für das tatsächliche Ergebnis?

Das Umgebungsfeld nennt, wo der Bug passiert ist, etwa Browser, Betriebssystem und Build-Stufe, während das Feld für das tatsächliche Ergebnis nennt, was passiert ist, etwa eine Fehlermeldung oder ein leerer Bildschirm. Ein Report kann genau nennen, was schiefging, und trotzdem nicht reproduzierbar sein, wenn er nie sagt, welcher Browser oder welche Umgebung es ausgelöst hat.

Macht automatische Bug-Ticket-Erstellung eine Bugreport-Vorlage überflüssig?

Automatische Bug-Ticket-Erstellung macht das Eintippen der Felder von Hand überflüssig, nicht die Felder selbst. Flowsery hängt Replay, Schritte zur Reproduktion und Umgebung automatisch an jedes Issue an, sodass ein Melder die Felder prüft und bestätigt, statt sie aus dem Gedächtnis neu einzutippen.

Wie lange sollte das Ausfüllen einer Bugreport-Vorlage dauern?

Eine Bugreport-Vorlage sollte so lange dauern, wie es braucht, um acht Fakten zu nennen, die ein Reviewer benötigt: Titel, Voraussetzungen, Schritte, erwartetes Ergebnis, tatsächliches Ergebnis, Schweregrad, Priorität und Umgebung. Ein Report, der deutlich länger dauert, füllt anstelle einer dieser Fakten nur Beschreibung auf; ein Report, der weniger Zeit braucht, hat eine davon ganz übersprungen.

Wer füllt eine Bugreport-Vorlage aus, der Melder oder der Reviewer?

Der Melder füllt bei der Ticketerstellung jedes Feld aus und nennt Titel, Voraussetzungen, Schritte, erwartetes und tatsächliches Ergebnis, Schweregrad, Priorität und Umgebung. Der Reviewer liest dieselbe Vorlage, um zu prüfen, ob nichts fehlt, bevor das Ticket einen Entwickler erreicht, und schickt es zurück, statt es selbst zu reparieren, wenn ein Feld leer ist. Wenn Session Replay die Schritte und die Umgebung automatisch anhängt, schrumpft der Anteil des Melders darauf, den Schweregrad zu bestätigen.

Was passiert, nachdem ein Reviewer einen Bugreport ablehnt?

Das Ticket geht zurück an den Melder, statt an einen Entwickler weiterzugehen. Der Melder muss ergänzen, was der Reviewer bemängelt hat, meist eine fehlende Voraussetzung oder ein erwartetes und tatsächliches Ergebnis, das in einem Satz zusammengefasst wurde, bevor das Ticket erneut ins Triage kommt. Niemand bewertet Schweregrad oder Priorität an einem zurückgeschickten Report, da ein Triager einen Bug, den er sich nicht vorstellen kann, nicht einstufen kann.

Warum sollten erwartetes und tatsächliches Ergebnis nicht einen Satz teilen?

Werden beide in einem Satz zusammengefasst, verdeckt das genau die Abweichung, die eine Fehlerbehebung schließen muss, und das ist der zweithäufigste Grund, warum Reviewer einen Report ablehnen. Als zwei getrennte Zeilen, etwa eine erwartete Meldung "Ungültiger Code" gegen eine tatsächliche leere weiße Seite, kann ein Entwickler die Lücke direkt erkennen, statt einen Absatz darüber zu lesen, wie sich der Bug angefühlt hat. Das Titel-Feld funktioniert erst, wenn diese Abweichung klar benannt ist, denn der Titel muss genau den Fehler nennen, den die beiden Zeilen beschreiben.

Spielt die Reihenfolge der Felder in einer Bugreport-Vorlage eine Rolle?

Die Reihenfolge spielt eine Rolle, weil jedes Feld vom vorherigen abhängt: Voraussetzungen müssen feststehen, bevor die Schritte sie voraussetzen können, und der Schweregrad wird bewertet, bevor die Priorität, damit die Dringlichkeit einen Schaden hat, auf den sie sich bezieht. Erwartetes und tatsächliches Ergebnis werden vor dem Titel geschrieben, da die Abweichung zwischen diesen beiden Zeilen das ist, was der Titel benennen muss. Diese Reihenfolge sorgt dafür, dass sich der Titel als letztes Feld praktisch von selbst schreibt.