10 häufige Fehler in Bugreports (und wie Sie sie vermeiden)

Ein Bugreport hat eine einzige Aufgabe: jemanden, der das Problem nie gesehen hat, in die Lage zu versetzen, es beim ersten Versuch nachzustellen. Die meisten Reports scheitern daran, und selten aus Mangel an Mühe. Sie scheitern an einer Handvoll Gewohnheiten, die sorgfältige Leute wiederholen, weil sie nie zugesehen haben, wie ihr eigener Report auf einem fremden Schreibtisch landet.

Jedes weggelassene Detail kostet Sekunden beim Hinschreiben und Stunden beim Nachholen: eine Runde durch einen Kommentarverlauf, ein Entwickler, der einen Zustand aufbaut, in dem Sie längst saßen, ein Ticket als nicht nachvollziehbar geschlossen und vierzehn Tage später von jemand anderem erneut eingereicht. Sie sind die einzige Person, die diesen Kontext je umsonst hat.

Zehn Gewohnheiten, in zwei Gruppen. Die ersten sechs sind Urteilsvermögen, und kein Werkzeug wird sie Ihnen je abnehmen. Die letzten vier sind Kontext, der im Moment des Fehlers vorhanden war und nicht aufgeschrieben wurde.

1. Ein Titel, der ein Gefühl beschreibt
2. Keine Schritte zum Nachstellen
3. Kein erwartetes Verhalten
4. Mehrere Bugs in einem Ticket
5. Emotion statt Auswirkung
6. Nicht auf Duplikate prüfen
7. Die Umgebung weglassen
8. Beschreiben, was Sie gesehen haben, statt es zu zeigen
9. Konsole und Netzwerk-Tab überspringen
10. “Bei mir läuft es”, ohne alles Weitere

Wenn Sie die Methode statt der Fallen suchen: das Begleitstück dazu, wie man einen perfekten Bugreport schreibt, hat die Anatomie eines guten Reports.

Was nur Sie schreiben können

1. Ein Titel, der ein Gefühl beschreibt

“Checkout ist kaputt.” “Login geht nicht.” “Irgendwas stimmt mit den Bildern nicht.”

Ein Titel wird viele Male gelesen und einmal geöffnet. Er taucht in Suchergebnissen auf, im Standup, in den Release Notes und in der Liste, die jemand morgens durchgeht, um zu entscheiden, was er heute anfasst. Ein Titel, der auf vierzig verschiedene Defekte passen würde, macht jeden dieser Momente langsamer.

Das Muster ist: was kaputt ging, dazu wo oder wann, dazu das eine Detail, das Ihren Fall von allen funktionierenden unterscheidet.

Schwach

Bilder kaputt

Besser

Produktbilder laden nicht in mobilem Chrome, wenn die Seite aus der Suche geöffnet wird

Streben Sie einen Satz an, den jemand laut wiederholen könnte, ohne das Ticket zu öffnen.

2. Keine Schritte zum Nachstellen

Ohne Schritte debuggt ein Entwickler nicht, er rät, was Sie getan haben. Jeder falsche Versuch endet in cannot reproduce, das Ticket kommt zu Ihnen zurück, und die Uhr läuft von vorn.

Schritte müssen in einem Zustand beginnen, den jeder erreichen kann.

Schwach

Geh in meinen Warenkorb und versuch zu bezahlen

Besser

1. Als Kunde mit leerem Warenkorb anmelden. 2. Zwei beliebige Artikel hinzufügen. 3. Den Code SAVE10 einlösen. 4. Auf Weiter zur Zahlung klicken.

Vier Zeilen, und der Leser steht dort, wo Sie standen. Geben Sie Ihre eigenen Schritte einer Kollegin, die den Bug nicht gesehen hat. Kommt sie mit einer Rückfrage, ist die Rückfrage Ihr fehlender Schritt.

3. Kein erwartetes Verhalten

“Die Summe ist falsch” setzt voraus, dass der Leser weiß, wie richtig aussieht. Oft weiß er es nicht, und manchmal stellt sich das, was Sie melden, als Regel heraus, die Sie nicht kannten.

Schreiben Sie beide Hälften.

Schwach

Der Rabatt stimmt nicht

Besser

Erwartet: Summe zeigt 45,00 nach 10 % Rabatt. Tatsächlich: Summe zeigt 50,00 und die Rabattzeile fehlt.

So finden Sie außerdem heraus, dass Sie und der Entwickler sich uneinig sind, wozu die Funktion da ist, und dieses Gespräch führt man besser im Ticket als drei Wochen später.

4. Mehrere Bugs in einem Ticket

Drei Probleme zusammen einzureichen fühlt sich effizient an. Es ist es nicht, denn ein Ticket hat einen Status. Sind zwei der drei behoben, ist das Ticket weder erledigt noch offen, und das dritte Problem verschwindet still unter einer Diskussion, die abgeschlossen aussieht.

Ein Defekt pro Ticket. Haben sie dieselbe Ursache, schreiben Sie das dazu und verlinken Sie sie.

5. Emotion statt Auswirkung

“Das ist unbenutzbar.” “Wie konnte das je ausgeliefert werden?” “Diese Woche das dritte Mal.”

Der Ärger ist berechtigt. Ein Bug hat gerade Ihren Nachmittag gefressen. Aber er verdrängt die Information, die das Ding reparieren würde, und er bringt den Leser in die Defensive, genau dann, wenn Sie seine Aufmerksamkeit auf dem Problem brauchen.

Auswirkung gehört in einen Bugreport. Nennen Sie sie als Tatsache und geben Sie dem Triage genug, um eine Priorität ohne Raten zu setzen: wie viele Leute betroffen sind, wie oft, ob Geld oder Daten im Spiel sind, ob es einen Weg drumherum gibt und ob es vorher funktionierte.

Schwach

Das ist eine Katastrophe, bitte ASAP fixen

Besser

Blockiert den Checkout für alle Safari-Kunden, kein Workaround, begann nach dem Release am Dienstag

Das zweite ist weit alarmierender als das erste und wird weit eher heute aufgegriffen. Ein Bug, der eine Person am Wechsel ihres Avatars hindert, und ein Bug, der jeden Kunden am Bezahlen hindert, sollten nie gleich aussehen, wenn sie ankommen.

6. Nicht auf Duplikate prüfen

Duplikate kosten zweimal: einmal, wenn jemand einen Report triagiert, der bereits bekannt ist, und noch einmal, wenn die Diskussion eines Problems auf zwei Tickets verteilt ist, sodass keines die ganze Geschichte enthält.

Durchsuchen Sie den Tracker nach der Fehlermeldung, dem Seitennamen und ein, zwei Wörtern aus dem Titel, den Sie gerade schreiben wollten. Suchen Sie auch in geschlossenen Tickets, denn ein Bug, der behoben war und wieder da ist, ist eine Regression, und das zu sagen ändert die Behandlung.

Suchen ist auch der schnellste Weg, die Wörter zu lernen, die Ihr Team tatsächlich benutzt. Wenn alle anderen es Korb nennen und Sie Warenkorb, wird Ihr Report von der nächsten suchenden Person nicht gefunden, und Sie finden ihren nicht.

Was der Browser schon weiß

Die vier folgenden sind anderer Art. Niemand lässt eine Browserversion weg, um Mühe zu sparen. Sie lassen sie weg, weil Aufschreiben bedeutet, die Seite zu verlassen, eine Versionszeichenkette zu suchen und sie in ein Formular zu tippen, und bis dahin ist der Tab zu.

7. Die Umgebung weglassen

Ein Bug, der überall auftritt, und ein Bug, der in einem Browser auftritt, sind verschiedene Bugs mit verschiedenen Ursachen, und niemand kann sagen, welchen Sie haben, bevor jemand nachsieht. So wird ein Report als nicht nachvollziehbar geschlossen: der Entwickler hat es in Chrome versucht, und Sie waren in Safari.

Halten Sie den Browser und seine Version fest, das Betriebssystem, das Gerät und die Fenstergröße, sobald das Layout überhaupt beteiligt ist. Latest Chrome ist keine Version. Es bedeutet an dem Tag, an dem es gelesen wird, etwas anderes als an dem Tag, an dem es geschrieben wurde.

8. Beschreiben, was Sie gesehen haben, statt es zu zeigen

Prosa ist ein verlustbehaftetes Format für ein visuelles Problem. “Das Layout wird unterhalb des Falzes komisch” kann ein halbes Dutzend Dinge heißen, und das halbe Dutzend hat verschiedene Lösungen.

Ein Screenshot klärt Layout- und Textprobleme auf der Stelle. Eine kurze Aufnahme ist besser für alles, woran Timing, Animation oder eine Folge von Interaktionen beteiligt ist. Nehmen Sie das ganze Fenster auf statt eines Ausschnitts der kaputten Stelle: die Adressleiste, die Konsole und die umgebende Seite enthalten oft die Antwort.

9. Konsole und Netzwerk-Tab überspringen

Das ist das Erste, wonach ein Entwickler fragt, und das Letzte, was die meisten Reports enthalten. Ein roter Fehler in der Konsole nennt meist die fehlerhafte Datei und die Zeile. Eine fehlgeschlagene Anfrage im Netzwerk-Tab nennt meist den Statuscode und den Endpunkt. Jedes von beiden kann einen Nachmittag Bisecting in eine Zweiminutenkorrektur verwandeln.

Öffnen Sie die Entwicklerwerkzeuge, bevor Sie den Tab schließen. Kopieren Sie den Fehlertext, statt ihn abzufotografieren, damit er durchsuchbar ist. Ist eine Anfrage fehlgeschlagen, notieren Sie ihren Status und ihren Pfad.

10. “Bei mir läuft es”, ohne alles Weitere

Der Satz beendet ein Gespräch, ohne etwas zu klären, und er wirkt in beide Richtungen. Von einem Entwickler heißt er, dem Report fehlte das Detail zum Nachstellen. Von einem Melder heißt es genau dasselbe umgekehrt, wenn er auf eine Korrektur mit “bei mir immer noch kaputt” und sonst nichts antwortet.

So oder so ist die Antwort Beleg statt Behauptung: die getestete Version, die Umgebung, in der Sie getestet haben, und was Sie gesehen haben. Ein Report über eine fehlgeschlagene Korrektur verdient dieselbe Sorgfalt wie der ursprüngliche.

Was die Hälfte davon tatsächlich löst

Sehen Sie sich die zweite Gruppe noch einmal an. Die Fehler 7, 8, 9 und 10 sind ein Problem mit vier Hüten: der Kontext war im Moment des Bugs vorhanden, und niemand hat ihn aufgeschrieben.

Das ist der Teil, der es wert ist, automatisiert zu werden, und deshalb haben wir Session Replay gebaut.

Es weiß nicht, worauf Sie geklickt haben. Es weiß, was der Browser wusste. Es wird also nicht Ihren Titel schreiben, Ihre drei Bugs auf drei Tickets aufteilen oder Ihnen sagen, was Sie erwartet haben. Das ist Urteilsvermögen, und es bleibt Ihres. Was es beseitigt, ist die Entschuldigung für die vier Gewohnheiten, bei denen es immer nur um Reibung ging, und übrig bleiben Ihnen die sechs, bei denen es ums klare Denken geht.

Die Checkliste

Bevor Sie auf Absenden drücken:

• Der Titel nennt, was fehlschlug, wo, und unter welcher Bedingung
• Die Schritte beginnen in einem Zustand, den jeder erreichen kann
• Erwartetes und tatsächliches Verhalten sind beide aufgeschrieben
• Ein Defekt in diesem Ticket, und nur einer
• Auswirkung als Tatsache genannt, mit genug für eine fremde Priorisierung
• Ich habe offene und geschlossene Tickets nach einem bestehenden Report durchsucht
• Browser, Version, Betriebssystem und Gerät sind festgehalten
• Ein Screenshot oder eine Aufnahme hängt an und zeigt das ganze Fenster
• Konsolenfehler und fehlgeschlagene Anfragen sind als Text eingefügt
• Belege für alles, was ich behaupte, einschließlich “es passiert immer noch”