Was visuelles Bug Reporting ist und worin es sich von Session Replay unterscheidet

Jemand auf Ihrer Website stößt auf einen Fehler. Diese Person kann ihn sehen: das kaputte Layout, den Knopf, der nichts tut, die rote Fehlermeldung. Bis das bei einem Entwickler ankommt, ist daraus ein Satz geworden. “Der Checkout ist kaputt.” Alles, was zu sehen war, ist weggeworfen, und die erste Aufgabe des Entwicklers besteht darin, es durch Nachfragen zu rekonstruieren.

Visuelles Bug Reporting ist die Praxis, festzuhalten, was auf dem Bildschirm war und was der Browser wusste, in dem Moment, in dem jemand beschlossen hat, ein Problem zu melden. Der Bericht ist der Beleg und nicht eine Beschreibung davon.

Was tatsächlich darin steckt

Das Wort “visuell” verkauft es unter Wert. Ein Bild ist der Teil, den man bemerkt; der größte Teil des Werts liegt darin, was der Browser hinter dem Bild getan hat.

Ein visueller Fehlerbericht enthält üblicherweise einiges oder alles davon:

• Einen Screenshot oder eine Aufzeichnung der Seite, so wie der Melder sie gesehen hat, oft mit etwas darauf gezeichnet, um auf das Problem zu zeigen.
• Die Umgebung: Browser und Version, Betriebssystem, Bildschirmgröße. Die Fakten, die entscheiden, ob ein Defekt universell ist oder zu einer einzigen Konfiguration gehört.
• Die Konsolenausgabe, einschließlich des Fehlers, der ausgegeben wurde, während niemand auf die Konsole geschaut hat.
• Das Netzwerkprotokoll: welche Anfragen die Seite gestellt hat, was zurückkam, wie lange es gedauert hat. Häufig ist die Antwort ein 403, den niemand gesehen hat.
• Was der Melder getan hat: die Klicks, die Formulareingaben und die Seitenwechsel, die dazu geführt haben, in ihrer Reihenfolge.

Der letzte Punkt ist es, der aus einem Bericht eine Anleitung macht. Aus dem Gedächtnis geschriebene Reproduktionsschritte sind eine Rekonstruktion; eine aufgezeichnete Abfolge ist ein Protokoll.

Worin es sich von Session Replay unterscheidet

Die beiden werden verwechselt, auch von uns: Unser Produkt heißt Session Replay, ein Name, den wir gewählt haben, und eine Kategorie, in der wir nicht sind.

Session Replay im üblichen Wortsinn ist eine Analytics-Praxis. Ein Skript läuft auf jeder Seite für jeden Besucher und zeichnet Sitzungen fortlaufend auf, damit sie später jemand ansehen kann, meist auf der Suche nach Mustern: wo Leute zögern, wo sie ein Formular abbrechen, welcher Rage-Click welchem Absprung vorausgeht. Niemand drückt irgendetwas. Die Aufzeichnung existiert, weil alle aufgezeichnet werden.

Visuelles Bug Reporting beginnt, wenn eine Person entscheidet, dass etwas nicht stimmt. Nichts wird aufgezeichnet, bevor sie handelt, und was dabei entsteht, richtet sich an einen bestimmten Leser mit einem bestimmten Defekt im Blick.

Session Replay

Immer an, jeder Besucher, hinterher angesehen, um Probleme zu finden, die niemand gemeldet hat

Visuelles Bug Reporting

Beginnt, wenn jemand meldet, erfasst einen Vorfall, geht an den, der ihn beheben kann

Der Unterschied ist aus zwei praktischen Gründen wichtig. Der erste ist Datenschutz: Ein Werkzeug, das standardmäßig alle aufzeichnet, muss dafür geradestehen, was es über Menschen gespeichert hat, die nie um etwas gebeten haben, und deshalb widmen Session-Replay-Werkzeuge einen so großen Teil ihrer Dokumentation dem Maskieren. Ein Bericht, den es nur gibt, weil jemand ihn einreichen wollte, hat eine sehr viel kleinere Frage zu beantworten.

Der zweite ist das Wiederfinden. Unter Tausenden die eine Sitzung zu finden, die den gemeldeten Fehler enthält, ist eine Aufgabe für sich. Ein Bericht kommt an und weiß bereits, um welchen Vorfall es geht.

Wo es das falsche Werkzeug ist

Visuelles Bug Reporting sieht nur das, was jemand zu melden beschlossen hat. Es sagt Ihnen nicht, wie viele andere Menschen auf denselben Defekt gestoßen und gegangen sind, und es bringt kein Problem zum Vorschein, über das sich niemand beschwert hat. Das beantwortet Analytics, und ein Fehlerbericht kann es nicht.

Ebenso nutzlos ist es für alles, was der Browser nicht sehen kann. Ein Job, der in einer Queue fehlgeschlagen ist, ein nächtlicher Import, der die falschen Zeilen geschrieben hat, ein Wettlauf zwischen zwei Diensten: Nichts davon steht auf einer Seite, und keine Menge an Bildschirmaufnahmen wird es finden. Dafür sind Logs und Tracing da.

Die ehrliche Position ist, dass dies drei Werkzeuge für drei verschiedene Fragen sind. Was für diese Person gerade jetzt schiefgegangen ist, ist die einzige, die ein visueller Fehlerbericht gut beantwortet.

Wie das in der Praxis aussieht

Die Version, die wir bauen, ist eine Chrome-Erweiterung. Jemand stößt auf einen Fehler, klickt auf das Symbol und bekommt einen Screenshot oder eine Aufzeichnung, an der die Umgebung, die Konsolenausgabe, das Netzwerkprotokoll und die Abfolge dessen hängen, was die Person getan hat. Sie bekommt einen Link, den sie dort einfügen kann, wo die Arbeit verfolgt wird. Für das Einreichen wird kein Konto benötigt.

Zwei Dinge, die sie nicht tut, denn eine Kategorieerklärung, die nur Stärken aufzählt, ist Werbung. Sie beobachtet nicht alle: Nichts wird aufgezeichnet, bevor jemand beschließt, etwas zu melden, also wird sie Ihnen nie von den Leuten erzählen, die auf denselben Defekt gestoßen sind und gegangen sind, ohne etwas zu sagen. Und sie entscheidet nicht, was wichtig ist. Der Titel, der Schweregrad und das Urteil darüber, ob zwei Symptome ein Defekt sind, bleiben bei der Person, die dabei war, und das ist das Thema von wie man einen perfekten Fehlerbericht schreibt.

Wenn Sie zwischen beiden wählen

Fragen Sie sich, welche Frage Sie beantworten wollen.

Lautet sie “warum brechen Leute dieses Formular ab”, brauchen Sie Analytics, und Session Replay gehört zu dieser Familie. Lautet sie “warum ist das für diese Person kaputtgegangen”, wollen Sie den Vorfall erfasst und an jemanden geschickt haben, und das ist Bug Reporting. Teams, die beides brauchen, betreiben in der Regel beides, und die zwei zu verwechseln ist der Weg dahin, vierhundert Aufzeichnungen anzusehen, um eine zu finden, die Ihnen jemand in fünfzehn Sekunden hätte reichen können.

Die Berichte selbst müssen immer noch gut geschrieben sein: Die Erfassung nimmt die Ausrede für fehlenden Kontext, nicht die Notwendigkeit eines klaren Titels und einer ehrlichen Schilderung dessen, was erwartet wurde. Die zehn häufigsten Fehler stehen einem Melder mit dem besten Werkzeug der Welt immer noch offen.