So diktieren Sie einen Fehlerbericht, den andere reproduzieren können

„Schon wieder kaputt“ ist eine ehrliche Fehlermeldung. Sie ist aber auch schwer zu beheben. Bis Sie den Issue-Tracker öffnen, sind der genaue Bildschirm, die Schaltfläche und das Ergebnis in der Erinnerung schon verschwommen. Einen Fehlerbericht zu diktieren kann diese Details festhalten, solange sie noch frisch sind – aber nur, wenn Sie dem Gesprochenen vorher eine Struktur geben.

Dieser kurze Ablauf macht aus einem beobachteten Fehler einen Bericht, mit dem andere das Problem reproduzieren können. Er funktioniert, ob Sie ein Nebenprojekt testen, bei der Arbeit ein Issue melden oder bei der Pflege eines Open-Source-Tools helfen. Genaue Befehle müssen Sie weiterhin eintippen und den fertigen Bericht prüfen. Die Stimme dient dazu, zu schildern, was passiert ist, nicht dazu, Belege zu erfinden.

Beginnen Sie mit dem Fehler, nicht mit einer Diagnose

Fehlerberichte geraten auf Abwege, wenn der Titel eine Theorie verkündet: „Der Datenbank-Cache ist kaputt.“ Vielleicht haben Sie recht, doch die Person, die den Fehler untersucht, braucht zuerst Ihre Beobachtung. Ein besserer Titel nennt Handlung und Ergebnis: „Beim Speichern eines Entwurfs wird die ausgewählte Sprache in den Einstellungen zurückgesetzt.“ Das lässt sich testen, ohne Ihre Theorie über die Ursache vorauszusetzen.

Dieselbe Regel hilft beim Diktieren. Sagen Sie in einem Satz, welche Aufgabe Sie erledigen wollten, und in einem weiteren, was die Software stattdessen getan hat. Beginnen Sie nicht mit einer langen Schilderung Ihrer Woche oder einer Vermutung darüber, welche Komponente ausgefallen ist. Wenn das Problem nur gelegentlich auftritt, sagen Sie das. Wenn es auf Ihrem Rechner jedes Mal passiert, sagen Sie auch das – aber behaupten Sie nicht, dass es bei allen auftritt.

GitHubs Anleitung zum Erstellen eines Issues beschreibt, wie man einen aussagekräftigen Titel und Text eingibt, und weist darauf hin, dass ein Repository eine Issue-Vorlage bereitstellen kann. Nutzen Sie diese Vorlage, falls es eine gibt. Die folgende Sprechstruktur hilft Ihnen, Fakten zu sammeln, bevor Sie die Felder ausfüllen; sie ist kein Grund, die Vorgaben des Projekts zu ignorieren.

Die Sprachnotiz mit fünf Feldern

Öffnen Sie einen leeren privaten Entwurf, statt den Bericht direkt in einem öffentlichen Issue-Tracker einzureichen. Klicken Sie in den Editor und diktieren Sie fünf kurze Felder. Beginnen Sie für jedes Feld eine neue Zeile. Ihr erster Entwurf sollte wie ein Augenzeugenbericht klingen, nicht wie eine ausgefeilte Versionsankündigung:

1. Kontext: Was wollten Sie tun? Nennen Sie die Seite, Funktion oder Aktion.
2. Schritte: Welche Handlungen haben den Fehler ausgelöst? Nummerieren Sie sie in der richtigen Reihenfolge.
3. Erwartet: Welches Ergebnis haben Sie vernünftigerweise erwartet?
4. Tatsächlich: Was ist auf dem Bildschirm passiert? Zitieren Sie eine kurze Fehlermeldung erst, nachdem Sie sie überprüft haben.
5. Umfang: Wann ist es passiert, in welcher Umgebung, und können Sie es wiederholen?

Hier ist eine Vorlage zum Kopieren und Einfügen. Ersetzen Sie jede eckige Klammer durch ein beobachtetes Detail. Wenn Sie etwas nicht wissen, schreiben Sie „nicht geprüft“, statt eine plausible Antwort zu erfinden.

Titel: [Aktion] verursacht [beobachtetes Ergebnis]
Kontext: Ich wollte [Ziel] in [Funktion/Seite] erreichen.
Schritte zum Reproduzieren:
1. [genauer Ausgangszustand]
2. [erste Aktion]
3. [nächste Aktion]
Erwartet: [was hätte passieren sollen]
Tatsächlich: [was passiert ist, einschließlich geprüftem Fehlermeldungstext]
Häufigkeit: [einmal / manchmal / bei jedem Versuch auf diesem Gerät]
Umgebung: [App-Version, Betriebssystem, gegebenenfalls Browser]
Belege: [unbedenklicher Screenshot oder bereinigtes Protokoll, falls hilfreich]

Lesen Sie die eckigen Klammern nicht einfach laut vor und erwarten Sie, dass daraus eine strukturierte Vorlage wird. Tragen Sie zuerst die Überschriften im Editor ein und diktieren Sie dann Feld für Feld. Wenn Sie eine Desktop-Sprachtastatur wie Talkpad unter macOS oder Windows verwenden, setzen Sie den Cursor in Ihren privaten Entwurf und diktieren Sie jeweils nur ein Feld. So können Sie jeden Teil vor dem Veröffentlichen leichter anhalten, prüfen und korrigieren.

Einmal reproduzieren, dann die Klicks beschreiben

Das Gedächtnis macht aus einer Abfolge eine Zusammenfassung. „Ich habe eine Einstellung geändert und die Seite ist abgestürzt“ lässt vielleicht das Neuladen, den Kontowechsel oder das ungespeicherte Formular aus. Wiederholen Sie die Abfolge, wenn es gefahrlos möglich ist, und lassen Sie den Entwurf neben der betroffenen App geöffnet. Halten Sie nach jeder Aktion inne und notieren Sie, was Sie getan haben. Lösen Sie einen Fehler, der Daten löscht oder Kosten verursacht, nicht immer wieder aus, nur um die Formulierung zu verbessern.

Formulieren Sie die Schritte wörtlich: „Einstellungen öffnen, Spanisch auswählen, auf Speichern klicken, Einstellungen erneut öffnen.“ Vermeiden Sie „zu den üblichen Optionen gehen und das machen“. Wenn Ihre App mehrere Speichern-Schaltflächen hat, nennen Sie den Bereich. Wenn der Fehler erst nach dem Neuladen auftritt, nehmen Sie diesen Schritt auf. Kolleginnen und Kollegen, die Ihren Bildschirm nie gesehen haben, sollten die Schritte ausführen können, ohne Sie nach dem fehlenden Klick fragen zu müssen.

Die Schilderung können Sie diktieren, aber für fehleranfällige Zeichenfolgen sollten Sie die Tastatur verwenden. Ein Modell kann einen Paketnamen in gewöhnliche Wörter umwandeln, die Groß- und Kleinschreibung eines Flags verändern oder ein Minuszeichen verschlucken. Fügen Sie einen geprüften Stacktrace oder Fehlertext aus der App ein, statt ihn zu sprechen. Das gilt auch für eine genaue Versionsnummer wie 1.4.12. In unserem Leitfaden zu Namen und Fachbegriffen finden Sie Hinweise zu weniger heiklen Wörtern, die dennoch sorgfältig geprüft werden sollten.

Erwartetes und tatsächliches Ergebnis trennen

Hier wird ein Bericht nützlich. „Das Formular hat nicht funktioniert“ sagt der untersuchenden Person fast nichts. „Nachdem ich auf Speichern geklickt hatte, erschien die Bestätigung, aber beim erneuten Öffnen der Einstellungen stand die Sprache wieder auf Englisch“ beschreibt eine beobachtbare Abweichung. Das erwartete Ergebnis kann ebenso schlicht sein: „Beim erneuten Öffnen der Einstellungen sollte weiterhin Spanisch als gespeicherte Sprache ausgewählt sein.“

Schmuggeln Sie keinen Lösungsvorschlag in das Feld für das erwartete Ergebnis. „Die App sollte einen anderen Cache verwenden“ ist ein Vorschlag zur Implementierung, keine aus Nutzersicht sichtbare Erwartung. Schreiben Sie eine mögliche Ursache bei Bedarf in eine klar gekennzeichnete Anmerkung am Ende und lassen Sie die Unsicherheit erkennbar. Ihre Kollegin oder Ihr Kollege könnte feststellen, dass die Ursache eine API-Antwort, ein veralteter Client oder etwas ganz anderes ist.

Wenn die Spracherkennung eine Verneinung falsch erfasst, kann der Bericht das Gegenteil dessen aussagen, was passiert ist. Vergleichen Sie „Das Dialogfenster wurde nicht geschlossen“ mit „Das Dialogfenster wurde geschlossen“. Lesen Sie diese Sätze vor dem Einreichen auf dem Bildschirm noch einmal durch. Unsere risikoorientierte Korrekturmethode stellt deshalb Verneinungen, Zahlen und Namen vor stilistische Änderungen.

Die Umgebung angeben, ohne ein forensisches Dossier anzulegen

Die kleinste nützliche Umgebungsangabe besteht meist aus der App-Version, dem Betriebssystem, gegebenenfalls dem Browser und allen Funktionseinstellungen, die für die Reproduktion nötig sind. Geben Sie nur dann an, ob sich der Fehler in einer frischen Sitzung oder auf einem anderen Gerät reproduzieren lässt, wenn Sie das tatsächlich getestet haben. Ein Zeitstempel oder die Netzwerkverbindung ist wichtig, wenn sie das Ergebnis beeinflusst; andernfalls erzeugt die Angabe nur Rauschen.

Prüfen Sie einen Screenshot, bevor Sie ihn anhängen. Benutzernamen, E-Mail-Adressen, Token, Kundendaten und Chat-Vorschauen können sich in den Ecken verstecken. Beschneiden Sie das Bild auf den relevanten Bereich oder machen Sie vertrauliche Details mit einem vertrauenswürdigen Bildbearbeitungsprogramm unkenntlich. Prüfen Sie Protokolle genauso sorgfältig. Wenn ein Issue-Tracker öffentlich ist, gehen Sie davon aus, dass auch der Anhang öffentlich sein wird. Bei Fragen zu Richtlinien am Arbeitsplatz lesen Sie unsere Datenschutz-Checkliste für Spracheingabe, bevor Sie vertrauliche Inhalte in irgendein Tool diktieren.

Talkpad kann einen gesprochenen Entwurf in die App einfügen, in der Ihr Cursor steht. Es prüft jedoch nicht, ob ein Screenshot unbedenklich oder ein Stacktrace korrekt ist. Das müssen Sie selbst kontrollieren. Wenn Ihre Unternehmensrichtlinien die Sprachverarbeitung von Vorfalldaten einschränken, halten Sie sich daran und schreiben Sie sensible Teile von Hand.

Zwei Prüfdurchgänge vor dem Einreichen

Im ersten Durchgang geht es um die Reproduzierbarkeit. Beginnen Sie beim angegebenen Ausgangszustand und folgen Sie Ihren Schritten genau. Tritt der Fehler auf? Sind das erwartete und das tatsächliche Ergebnis verschieden und verständlich beschrieben? Haben Sie einen Anmeldeschritt oder eine Einstellung ausgelassen, die das Ergebnis verändert? Wenn Sie den Fehler nicht erneut reproduzieren können, passen Sie das Feld zur Häufigkeit entsprechend an, statt die Unsicherheit zu verschweigen.

Im zweiten Durchgang geht es um Risiken. Vergleichen Sie Versionsangaben und Fehlermeldungen mit ihren Quellen. Entfernen Sie Geheimnisse aus dem Text und den Anhängen. Ersetzen Sie Vermutungen durch beobachtbare Fakten oder kennzeichnen Sie sie als Hypothese. Kürzen Sie die Einleitung, wenn sie den Zugang zu den Schritten verzögert. Das Werkzeugset zum Bearbeiten diktierter Entwürfe kann helfen, wenn der erste Entwurf eher ein zusammenhängender Redefluss als eine Liste sauberer Felder ist.

Ein nützlicher Bericht muss nicht lang sein. Manche Fehler brauchen drei Schritte und zwei Sätze, andere ein kontrolliertes Beispiel. Verzichten Sie auf Füllmaterial. Ziel ist, dass jemand anderes das Verhalten reproduzieren und verstehen kann, warum Sie etwas anderes erwartet haben. Wenn Sie den Ausgangszustand nicht erklären können, untersuchen Sie das Problem vor der Veröffentlichung noch etwas genauer.

Häufig gestellte Fragen

Kann ich einen Fehlerbericht diktieren?

Ja. Diktieren Sie den Kontext, die Reproduktionsschritte und das erwartete sowie das tatsächliche Verhalten in einen privaten Entwurf. Tippen und prüfen Sie genaue Befehle, Fehlermeldungen, URLs und Versionsnummern, bevor Sie ihn teilen.

Was gehört in einen Fehlerbericht?

Ein aussagekräftiger Titel, der Ausgangskontext, geordnete Schritte, das erwartete Ergebnis, das tatsächliche Ergebnis, die relevante Umgebung und bei Bedarf unbedenkliche Belege. Folgen Sie der Issue-Vorlage des Repositorys, falls eine vorhanden ist.

Wie melde ich einen Fehler, den ich nicht reproduzieren kann?

Geben Sie an, dass er einmal oder nur gelegentlich aufgetreten ist, halten Sie Ihre Beobachtungen und die Ihnen bekannte Umgebung fest und nennen Sie die Versuche, bei denen er nicht erneut auftrat. Füllen Sie unbekannte Schritte nicht mit Vermutungen.

Sollte ich Protokolle an ein öffentliches Issue anhängen?

Nur nachdem Sie sie auf Geheimnisse und personenbezogene Daten geprüft haben. Entfernen oder schwärzen Sie sensible Informationen und teilen Sie nur den kleinsten Ausschnitt, der den Fehler verständlich macht. Halten Sie sich an die Regeln Ihres Teams für Vorfälle und Datenschutz.

Talkpad kostenlos herunterladen – 2.500 Wörter pro Woche im kostenlosen Tarif.