Warum Schritte zur Reproduktion entscheiden, ob ein Bug behoben wird

Was sind Schritte zur Reproduktion in einem Bugreport?

Ein Bugreport verdient das Label reproduzierbar, wenn seine Schritte zur Reproduktion die genauen nummerierten Aktionen, den Startzustand und die Eingaben auflisten, die nötig sind, um den Fehler erneut auszulösen. Jeder, der die Liste liest, nicht nur die Person, die den Bug gefunden hat, sollte ihr folgen und beim selben Fehler landen können. Schreib die Schritte als kurzes Skript für eine andere Person, nicht als Zusammenfassung dessen, was passiert ist, oder häng einen Session Replay an, sodass sich das Skript aus der Aufzeichnung von selbst schreibt.

Was enthält ein vollständiger Abschnitt mit Schritten zur Reproduktion?

Ein vollständiger Abschnitt nennt fünf Dinge: die Voraussetzungen, die nummerierten Aktionen, das erwartete Ergebnis, das tatsächliche Ergebnis und die Umgebung. Fehlt eines davon, wird aus einem reproduzierbaren Bug eine Vermutung, denn ein Entwickler ohne Startzustand muss ihn erst rekonstruieren, bevor er die Schritte überhaupt versuchen kann. Dasselbe Detail entscheidet auch über Schweregrad vs. Priorität, denn wer ohne vollständige Reproduktion bewertet, rät sowohl beim Schaden als auch bei der Dringlichkeit.

Warum sind Voraussetzungen vor den nummerierten Schritten wichtig?

Voraussetzungen sind wichtig, weil dieselbe Klickfolge je nach Ausgangszustand des Nutzers unterschiedliche Ergebnisse liefert. "Auf Checkout klicken" verhält sich bei einem leeren Warenkorb anders als bei einem bereits angewendeten Gutschein, weshalb eine Schrittliste ohne Voraussetzungen dem Entwickler zwar die Aktionen gibt, aber nicht die Startlinie. Nenne den Kontotyp, die bereits vorhandenen Daten und alle vorherigen Aktionen in derselben Sitzung vor Schritt eins.

Wie sollten erwartetes und tatsächliches Verhalten beschrieben werden?

Erwartetes und tatsächliches Verhalten gehören auf getrennte Zeilen, jede mit einem konkreten Ergebnis statt einem Gefühl zum Bug. Schreib das erwartete Ergebnis als das, was die Oberfläche eigentlich zeigen sollte, und das tatsächliche Ergebnis als genau das, was stattdessen erschien, einschließlich Fehlertext, einer leeren Seite oder eines falschen Werts. "Die Seite sieht kaputt aus" reproduziert nichts; "erwartet wurde die Meldung 'Ungültiger Code', tatsächlich erschien eine leere weiße Seite ohne Konsolenausgabe" gibt dem Entwickler ein konkretes Ziel zum Abgleich.

Welche Umgebungsdetails gehören in einen Bugreport?

Umgebungsdetails umfassen Browser und Version, Betriebssystem, Bildschirmgröße, Netzwerkbedingungen und ob der Bug in Produktion, Staging oder einem lokalen Build aufgetreten ist. Ein Layoutfehler, der an Safaris Flexbox-Handling hängt, oder ein Timing-Fehler, der an einer langsamen Verbindung hängt, verschwindet, sobald ihn jemand auf einem anderen Setup testet, weshalb die Zeile zur Umgebung aus "Ich kann das nicht reproduzieren" ein "Ich habe den falschen Browser getestet" macht.

Warum passiert "geht bei mir"?

"Geht bei mir" passiert, wenn Melder und Entwickler stillschweigend unterschiedliche Voraussetzungen oder Umgebungen verwenden, nicht weil der Bug erfunden ist. Ein Feature-Flag, das bei einem Konto aktiv und bei einem anderen deaktiviert ist, ein veralteter Cache, eine andere Bildschirmbreite oder eine Browser-Erweiterung, die ein Skript blockiert, reproduzieren den Fehler für eine Person und verstecken ihn vor der nächsten. Behandle den Satz als fehlendes Feld im Report und geh zurück, um Umgebung und Voraussetzungen nachzutragen, statt das Ticket zu schließen.

Wie verkürzt Session Replay das Schreiben von Schritten zur Reproduktion?

Session Replay verkürzt die Ausarbeitung, weil die Aufzeichnung bereits jeden Klick, jede Eingabe und jeden Seitenzustand enthält, den ein manueller Report von Hand beschreiben müsste. Flowsery hängt Replay und Schritte zur Reproduktion automatisch an jeden Issue und Bugreport an, sobald er in Slack, Linear oder Jira landet, sodass ein Entwickler die genaue Abfolge sieht, statt der Erinnerung eines Nutzers an seine Klicks zu vertrauen. Rage Clicks und Dead Clicks markieren den Moment, in dem der Nutzer auf den Fehler stieß, was das Rätselraten beseitigt, wo im Ablauf man suchen soll, und @flowsery im selben Slack-Thread zu markieren öffnet einen Pull-Request-Entwurf, sobald die Lösung klar ist.

Häufig gestellte Fragen

Was macht Schritte zur Reproduktion gut statt vage?

Gute Schritte zur Reproduktion sind nummeriert, starten mit einer genannten Voraussetzung und enden mit einem genannten erwarteten Ergebnis neben dem tatsächlichen. Ein vager Report beschreibt ein Gefühl ("Checkout ist kaputt"); ein guter listet fünf Klicks auf, was hätte erscheinen sollen und was stattdessen erschien.

Was ist der Unterschied zwischen Schritten zur Reproduktion und einer Bugbeschreibung?

Eine Bugbeschreibung erklärt in Prosa, was schiefgelaufen ist, während Schritte zur Reproduktion ein Skript sind, das eine andere Person ausführen kann, um denselben Fehler zu sehen. Ein Report kann eine klare Beschreibung haben und trotzdem nicht reproduzierbar sein, wenn er die nummerierten Aktionen oder den Startzustand auslässt.

Warum kann ein Entwickler einen von einem Kunden gemeldeten Bug nicht reproduzieren?

Ein Entwickler kann einen gemeldeten Bug meist nicht reproduzieren, weil dem Report eine Voraussetzung oder ein Umgebungsdetail fehlt, etwa ein Kontostatus, eine Browserversion oder ein Feature-Flag, das sich zwischen den beiden Setups unterscheidet. Der Bug ist echt; der Report ist unvollständig.

Was gehört in den Umgebungsabschnitt eines Bugreports?

Der Umgebungsabschnitt sollte Browser und Version, Betriebssystem, Bildschirmgröße, Netzwerkbedingungen und ob der Bug in Produktion, Staging oder lokal auftrat, nennen. Jedes dieser Details kann verändern, ob ein Bug überhaupt auftritt.

Wie viele Schritte sollte eine Reproduktion haben?

Eine Reproduktion sollte so viele nummerierte Schritte haben, wie es einzelne Aktionen gibt, die der Nutzer vor dem Fehler ausgeführt hat, nicht mehr und nicht weniger. Zwei Aktionen zu einem Schritt zusammenzufassen oder die Liste mit Schritten aufzufüllen, die das Ergebnis nicht beeinflussen, macht den Report schwerer statt leichter nachvollziehbar.

Ersetzt Session Replay geschriebene Schritte zur Reproduktion?

Session Replay ersetzt die Notwendigkeit, die nummerierten Aktionen von Hand zu schreiben, da die Aufzeichnung die genauen Klicks, Eingaben und Seitenzustände in der richtigen Reihenfolge zeigt. Umgebung und Voraussetzungen werden weiterhin automatisch mit dem Replay verknüpft, sodass der Entwickler ein Issue öffnet, statt den Melder nach fehlenden Details zu fragen.

Warum zählt "die Seite sieht kaputt aus" nicht als Bugreport?

"Die Seite sieht kaputt aus" beschreibt ein Gefühl, kein Ergebnis, und gibt einem Entwickler nichts zum Abgleichen. Ein Bericht braucht zwei getrennte Zeilen: was die Oberfläche zeigen sollte, und was stattdessen tatsächlich erschien, inklusive Fehlertext oder leerem Bildschirm. Vergleiche das mit "erwartet wurde die Meldung 'Invalid code', stattdessen erschien eine leere weiße Seite ohne Konsolenausgabe", das zeigt genau, wonach zu suchen ist.

Wie wirken sich Schritte zur Reproduktion auf Severity und Priority aus?

Ein Bewerter ohne vollständige Reproduktionsschritte muss sowohl den Schaden eines Bugs als auch die Dringlichkeit der Behebung schätzen. Voraussetzungen, nummerierte Schritte, erwartetes Ergebnis, tatsächliches Ergebnis und Umgebung sagen einem Triager zusammen, was wirklich kaputtgeht und für wen. Fehlt eines dieser Felder, werden Severity und Priority zu Schätzungen statt zu Entscheidungen.

Was bringen Rage Clicks und Dead Clicks einem Bugreport?

Rage Clicks und Dead Clicks markieren den genauen Moment, in dem ein Nutzer im Session Replay auf den Fehler gestoßen ist. Dieser Zeitpunkt erspart das Suchen danach, wo in einer aufgezeichneten Sitzung der Bug zu finden ist. Zusammen mit den automatisch angehängten Schritten zur Reproduktion springt ein Entwickler direkt zum Fehler, statt die ganze Sitzung durchzuscrollen.

An welche Tools hängt Flowsery Schritte zur Reproduktion automatisch an?

Flowsery hängt den Session Replay und die Schritte zur Reproduktion automatisch an jedes Issue an, sobald es in Slack, Linear oder Jira landet. Ein Entwickler sieht dann die genaue Abfolge von Klicks und Eingaben, statt sich auf die Erinnerung des Melders zu verlassen. Ein @flowsery-Tag im selben Slack-Thread kann außerdem einen Entwurf für einen Pull Request öffnen, sobald der Fix klar ist.