Wie Sie einen Bug reproduzieren, und was zu tun ist, wenn Ihnen das nicht gelingt

„Cannot reproduce“ (nicht reproduzierbar) ist die häufigste Art, wie ein Fehlerbericht endet, und es lohnt sich, den Satz genau zu lesen, denn er sagt nicht das, was die meisten Leute glauben. Er ist keine Aussage über den Bug. Er ist eine Aussage über zwei Umgebungen: die des Berichterstatters, in der es passiert ist, und Ihre, in der es nicht passiert ist.

Der Bug selbst steht nicht in Frage. Jemand hat live miterlebt, wie er auftrat. Infrage steht, ob Sie die Bedingungen herstellen können, die er brauchte, und meistens enthält der Bericht diese Bedingungen nicht, weil die Person, die ihn geschrieben hat, keine Ahnung hatte, welches der tausend Dinge um sie herum eine Rolle spielte.

Was eine Reproduktion wirklich braucht

Schritte sind nur eines von vier Dingen, und es ist das, an das jeder zuerst denkt.

Die gleichen Schritte. Was angeklickt wurde, in der richtigen Reihenfolge, ausgehend von einem Punkt, an dem Sie ebenfalls starten können.

Der gleiche Zustand. Das Konto, die Berechtigungen, die Feature-Flags, die vor achtzehn Monaten geänderten Einstellungen, der halbfertige Entwurf, der noch in der Datenbank liegt. Daran scheitern die meisten Versuche, denn der Zustand ist für die Person darin unsichtbar. Sie weiß nicht, dass ihr Konto ungewöhnlich ist. Es ist einfach ihr Konto.

Die gleichen Daten. Kein frischer Testdatensatz, sondern der konkrete: die Bestellung mit einer Rückerstattung, der Name mit einem Apostroph, die leere Liste, der Upload mit vierzig Megabyte. Seed-Daten sind aufgeräumt. Produktionsdaten sind fünfzehn Jahre an Entscheidungen, und das ist die gleiche Lücke, die Staging zur Lüge macht.

Die gleiche Umgebung. Browser und Build, Gerät, Netzwerk, Bildschirmgröße, Uhrzeit, Erweiterungen. Allein die Version kann schon ausschlaggebend sein: “latest Chrome” war in einer Woche drei verschiedene Hauptversionen.

Vier Achsen, und ein Bericht legt meist nur eine davon fest. Die eigentliche Arbeit beim Reproduzieren besteht darin, die anderen drei zu erraten, weshalb es einen ganzen Nachmittag dauert und so oft mit einem Achselzucken endet.

Beginnen Sie beim Zustand, nicht bei den Schritten

Der erste Impuls ist, den Schritten zu folgen und zu sehen, was passiert. Der bessere erste Schritt ist zu fragen, was wahr sein müsste, damit diese Schritte tatsächlich fehlschlagen.

Wenn der Checkout an der Zahlungsstufe abbricht, sind die Schritte drei Klicks, die jeder ausführen kann. Was nicht universell ist, sind der Warenkorb, die Adresse, die Zahlungsmethode, die Währung, ob diesem Konto schon einmal eine Rückerstattung gutgeschrieben wurde. Finden Sie heraus, welche dieser Faktoren das Ergebnis verändern könnten, und schon wird aus einem vagen Bericht ein Satz von drei oder vier konkreten Experimenten.

Schwach

Schritte auf einem Testkonto ausgeführt. Funktioniert einwandfrei. Als "cannot reproduce" geschlossen.

Besser

Auf einem frischen Konto funktionieren die Schritte. Im Konto des Berichterstatters liegt eine gespeicherte Karte aus einer Währung, die wir nicht mehr unterstützen, und der Fehler steckt in der Währungsabfrage. Reproduziert, indem eine solche Karte einem Testkonto hinzugefügt wurde.

Die zweite Version bedeutet nicht mehr Aufwand. Es ist derselbe Aufwand, nur auf die richtige Frage gerichtet.

Reduzieren Sie die Reproduktion auf das kleinste Element, das noch fehlschlägt

Sobald es zuverlässig fehlschlägt, nehmen Sie Teile weg. Entfernen Sie einen Schritt, entfernen Sie ein Feld, verwenden Sie eine kleinere Datei, schalten Sie eine Erweiterung aus, kürzen Sie die Daten. Jede Entfernung führt entweder dazu, dass der Fehler bestehen bleibt, dann war dieses Teil nicht nötig, oder dazu, dass er verschwindet, dann haben Sie gerade etwas gefunden, das wichtig ist.

Das lohnt sich sogar dann, wenn Sie den Fix schon haben, und zwar aus zwei Gründen. Eine minimale Reproduktion ist ein Testfall, den man behalten kann. Und das Minimieren findet die Ursache sehr oft, bevor Sie auch nur einen Blick in den Code geworfen haben: Der Bug, der nur überlebt, wenn die Liste leer ist, verrät Ihnen damit bereits, worum es sich handelt.

Achten Sie auf die Reproduktion, die nur manchmal funktioniert. Das ist keine gescheiterte Reproduktion, sondern eine andere Art von Bug, und die Unregelmäßigkeit ist ein Datenpunkt, kein Rauschen: Irgendetwas läuft in einem Wettlauf, hängt von der Reihenfolge ab, oder von einem noch kalten Cache. Dieselbe Logik, nach der sich ein flakiger Test eher untersuchen als nur erneut ausführen lässt, gilt auch hier.

Die Fälle, die sich prinzipbedingt nicht reproduzieren lassen

Manche Fehler lassen sich auf Ihrer Maschine grundsätzlich nicht nachstellen, und noch so viel Ausdauer ändert daran nichts. Sie früh zu erkennen, ist mehr wert, als es einfach härter zu versuchen.

Es brauchte ihre Uhr. Ein Gerät mit falscher Uhrzeit erzeugt Zertifikatsfehler, abgelaufene Sitzungen und unmögliche Zeitstempel. Das waren drei der fünf Ursachen hinter einer Zertifikatswarnung.

Es brauchte ihr Netzwerk. Ein Firmenproxy, ein DNS-Filter, ein Captive Portal, ein Mobilfunkanbieter, der Anfragen umschreibt. Sie können diesem Netzwerk nicht beitreten, also können Sie auch nicht sehen, was es tut.

Es brauchte ihren Build. Ein gestaffelter Rollout hat einen Bruchteil der Nutzer auf eine Version gebracht, die sonst niemand hat, auch Sie nicht.

Es brauchte den Moment. Ein Deploy mitten im Vorgang, ein noch kalter Cache, ein Drittanbieterdienst, der neunzig Sekunden lang langsam war. Der Zustand, der das ausgelöst hat, existierte nicht mehr, als der Bericht geschrieben wurde.

Es brauchte ihre Erweiterungen. Etwas, das in die Seite injiziert wurde, hat sie verändert. Sie haben andere Erweiterungen, also haben Sie eine andere Seite.

Bei diesen Fällen lautet die Frage nicht „Wie reproduziere ich das“, sondern „Was war in diesem Moment wahr, und kann ich das noch herausfinden?“

Was dafür spricht, stattdessen aufzuzeichnen

Jeder Punkt auf dieser Liste ist im Nachhinein unsichtbar, aber im Moment des Geschehens billig zu erfassen. Die Konsole in dem Moment, in dem es kaputtging. Die fehlgeschlagene Anfrage mit ihrem Status und ihrer Zeitmessung. Der Browser-Build, die Bildschirmgröße, die URL. Nichts davon verlangt vom Berichterstatter, zu wissen, was wichtig ist, und genau das ist die eigentliche Schwierigkeit, denn das weiß er nie.

Das ist das Argument für einen Bericht, der seine Beweise selbst mitbringt, statt nur eine Beschreibung davon zu liefern. Reproduktion ist ein Weg, Informationen zurückzugewinnen, die weggeworfen wurden, und genau deshalb ist sie so aufwendig: weil die Informationen weggeworfen wurden.

Den Berichterstatter richtig erneut befragen

Wenn Sie doch noch einmal nachfragen müssen, fragen Sie nach den Dingen, die die Person tatsächlich beantworten kann, nicht nach den Dingen, die Sie sich gewünscht hätten, dass sie geschrieben hätte.

Schlecht: „Bitte geben Sie die genauen Schritte zur Reproduktion an.“ Sie glauben ohnehin bereits, das getan zu haben.

Besser, und jede dieser Fragen hat eine ordentliche Trefferquote:

• Um welche Uhrzeit ist es passiert, und welche Uhrzeit zeigt Ihr Gerät gerade an? Zwei Fragen, keine einzige. Der Abstand zwischen den beiden Antworten ist bereits eine Diagnose.
• Ist es schon mehr als einmal passiert? Einmal ist ein Moment. Wiederholt ist ein Zustand.
• Passiert es auch in einem anderen Netzwerk, zum Beispiel mit mobilen Daten statt WLAN?
• Was genau steht auf dem Bildschirm? Die Worte selbst, keine Zusammenfassung davon.
• Mit wem können Sie es noch reproduzieren? Ein anderes Konto grenzt es auf die Daten ein, eine andere Person am gleichen Konto grenzt es auf das Gerät ein.

Der Leitfaden für Fehlerberichte zeigt die vollständige Struktur eines guten Berichts, und die häufigsten Fehler beschreiben, was am häufigsten fehlt.

Was Sie schreiben, wenn Sie aufgeben

Manchmal gelingt es Ihnen wirklich nicht, und es zu schließen ist die richtige Entscheidung. Schließen Sie es aber nicht nur als “cannot reproduce” ohne weitere Angaben, denn dieser Satz sagt der nächsten Person nichts, und sie wird denselben Nachmittag verlieren wie Sie.

Schreiben Sie auf, was Sie versucht haben. Welches Konto, welcher Browser und Build, welche Daten, welche der vier Achsen Sie variiert haben und welche nicht. Dann ist der nächste Bericht über dasselbe Problem, von einer anderen Person mit einem anderen Detail, kein Neuanfang. Er ist der zweite Datenpunkt, und zwei Berichte, die eine Gemeinsamkeit in etwas Ungewöhnlichem haben, sind meist schon die ganze Antwort.

Das ist auch die ehrliche Version des Status. Der Bug wurde nicht widerlegt. Er wurde mit den verfügbaren Informationen nicht reproduziert, was eine andere Aussage ist und eine, die als Hinterlassenschaft deutlich nützlicher ist.