Was tun mit einem Fehlerbericht, den du nicht reproduzieren kannst
Ein systematischer Umgang mit Bugs, die du nicht reproduzieren kannst: die üblichen Ursachen, der Kontext, der sie aufklärt, und wie du verhinderst, dass sie wiederkommen.
Ideen, Tutorials und Updates von unserem Team.
Ein systematischer Umgang mit Bugs, die du nicht reproduzieren kannst: die üblichen Ursachen, der Kontext, der sie aufklärt, und wie du verhinderst, dass sie wiederkommen.
Ein Third-Party-Widget, das jedem Besuch 450 KB ausliefert, muss das rechtfertigen können. Meines konnte es nicht. Die Messung, die Lösung und warum ich mich bei defer geirrt hatte.
Eine UAT-Runde liefert eine Tabelle mit sechzig Zeilen, und mit der Hälfte davon kann niemand etwas anfangen. Selten liegt es an den Testpersonen. Es liegt am Meldekanal, der die Belege genau in dem Moment wegwirft, in dem es sie gibt.
Mit MCP kann ein KI-Agent dein Produkt lesen. Das ist der einfache Teil. Schwer ist es, Tools zu entwerfen, die ein Agent gleich beim ersten Versuch richtig benutzt, und das ist eine andere Disziplin als das Design einer REST-API.
„Nicht reproduzierbar“ ist keine Eigenschaft des Bugs. Es ist eine Aussage über den Unterschied zwischen zwei Rechnern. Solche Unterschiede gibt es nur etwa acht, und jeder hinterlässt einen eigenen Fingerabdruck.
Jedes Team schreibt irgendwann eine Vorlage für Fehlerberichte. Die meisten werden nach einem Monat ignoriert, weil sie Leuten Arbeit abverlangen, die ein Browser für sie erledigen könnte. Hier ist eine Vorlage, die sich zu behalten lohnt, und warum du drei Viertel davon streichen solltest.
Die DevTools sind auf dem falschen Rechner offen. Wie du Console, Fehler, fetch und XHR instrumentierst, damit dir ein fremder Browser sagt, was wirklich passiert ist, und an welchen Fallen naive Implementierungen genau die Seite kaputtmachen, die sie überwachen.
Berichte und Aufgaben zu trennen ist eine kleine strukturelle Entscheidung. Sie verhindert, dass dein Bug-Eingang zum Friedhof wird, und macht doppelte Berichte zu deinem besten Werkzeug fürs Debugging.
Session-Replay hat ein Imageproblem, und das meiste davon ist verdient. So nutze ich es: an einen Bericht gebunden, von der meldenden Person weichzuzeichnen und mit einer Zeile abschaltbar.
Ich habe einen MCP-Server gebaut, damit Claude Code Fehlerberichte, Console-Logs und Netzwerk-Traces selbst abrufen kann. Das Ergebnis ist ein Debugging-Ablauf, bei dem du das Dashboard nie öffnest.
Ein Rundgang durch jedes Signal, das das BugDump-Widget sammelt: warum es seinen Platz verdient und welche Signale tatsächlich Bugs lösen.
Wer entwickelt, kennt dieses Hin und Her. Jemand meldet, dass etwas kaputt ist, du fragst nach dem Browser, und bis die Antwort kommt, ist eine Stunde weg. Ich hatte genug davon.