Klare Fehlerberichte schneller schreiben mit Spracheingabe

Du entdeckst bei der Arbeit einen Fehler, doch ihn zu beschreiben wird zur nächsten Aufgabe. Nach dem Wechsel ins Ticketsystem versuchst du, dich an die genaue Reihenfolge zu erinnern. Am Ende steht dort nur: „Export funktioniert nicht.“ Wer den Fehler untersucht, muss erst nachfragen, welcher Export gemeint ist und was genau passiert ist.

Spracheingabe bietet einen einfachen Einstieg: Beschreibe den Ablauf, solange die Details frisch sind, und strukturiere anschließend den Text. Den Zusammenhang erklärst du mündlich; Angaben, die exakt stimmen müssen, ergänzt du per Tastatur oder Kopieren. Das eignet sich für Entwicklung, Qualitätssicherung und Support ebenso wie für andere Menschen, die am Mac arbeiten.

1. Vor dem Aufgabenwechsel ein Problem beschreiben

Beginne mit einer kurzen Erklärung deines Ziels. Nenne den Ausgangszustand, deine Handlung und das beobachtete Ergebnis. Beschränke jeden Bericht auf einen Fehler.

Für eine fiktive Aufgaben-App könnte ein erstes Diktat so klingen:

Ich habe die Ansicht für erledigte Aufgaben geöffnet und die Liste als CSV exportiert. Auf dem Bildschirm waren vier erledigte Aufgaben zu sehen. Die heruntergeladene Datei enthielt aber auch offene Aufgaben. Ich hatte erwartet, dass der Export der gefilterten Ansicht entspricht. Beim zweiten Versuch aus derselben Ansicht kam dasselbe heraus.

Das ist noch kein fertiger Bericht, aber eine brauchbare Grundlage. Du hältst den Ablauf fest, ohne beim Sprechen bereits jedes Feld ausformulieren zu müssen.

2. Aus der Beschreibung reproduzierbare Schritte machen

Überarbeite den Entwurf so, dass eine andere Person ihn nachvollziehen kann. Ersetze „der Knopf“ durch die tatsächliche Beschriftung und ergänze die notwendigen Voraussetzungen.

Der Bericht zum fiktiven Beispiel könnte so aussehen:

• Titel: CSV-Export enthält offene Aufgaben aus der Ansicht für erledigte Aufgaben.
• Voraussetzung: Ein Testprojekt enthält vier erledigte und zwei offene Aufgaben.
• Schritte: Projekt öffnen, nach erledigten Aufgaben filtern, CSV exportieren und die heruntergeladene Datei öffnen.
• Erwartetes Ergebnis: Die CSV enthält nur die vier erledigten Aufgaben der gefilterten Ansicht.
• Tatsächliches Ergebnis: Die CSV enthält alle sechs Aufgaben, einschließlich der zwei offenen.
• Reproduzierbarkeit: Bei zwei Versuchen mit demselben Testprojekt beobachtet.
• Auswirkung: Vor dem Teilen der Liste müssen überflüssige Zeilen manuell entfernt werden.

Kopiere außerdem die Versionen der betroffenen App und des Betriebssystems in den Bericht. Bei einem Browserproblem gehört auch die Browserversion dazu. Beschreibe nur die tatsächlich getestete Umgebung, ohne Versionsnummern zu schätzen.

3. Zusammenhänge diktieren, genaue Zeichenfolgen kopieren

Sprache eignet sich gut, um den Ablauf und die Bedeutung eines Problems zu erklären. Fehlercodes, Dateipfade, URLs und Versionsnummern kopierst du besser direkt aus der Quelle. Schon ein fehlendes Zeichen kann die Untersuchung in die falsche Richtung lenken.

Nach dem Diktieren kannst du die Schritte nummerieren oder eine kurze Fehlermeldung einfügen. Ergänze bei Bedarf einen Screenshot oder einen passenden Log-Auszug als separaten Beleg. Spracheingabe erstellt den Textentwurf; sie überprüft den Fehler nicht selbst und hängt solche Belege nicht automatisch an.

Trenne außerdem Beobachtung und Vermutung. „Die Datei enthält sechs Aufgaben“ beschreibt ein Ergebnis. „Ein Cache-Fehler sorgt dafür, dass der Filter ignoriert wird“ ist ohne bestätigte Ursache nur eine Hypothese. Kennzeichne sie entsprechend.

4. Eine wiederverwendbare Vorlage bereithalten

Speichere diese Fragen in deinen Notizen oder im Ticketsystem und diktiere jeweils eine kurze Antwort:

• Was ist das Problem in einem Satz?
• Welche Umgebung und welchen Ausgangszustand habe ich verwendet?
• Welche Schritte habe ich in welcher Reihenfolge ausgeführt?
• Was habe ich erwartet, und was ist tatsächlich passiert?
• Wie oft habe ich das Verhalten beobachtet?
• Welche Arbeit wird behindert, und gibt es eine Zwischenlösung?
• Welche Belege sollte ich anhängen?

Wenn der Fehler nur einmal aufgetreten ist, schreibe genau das. Eine nicht getestete Zwischenlösung bleibt unbestätigt. Ein präziser Bericht mit begrenzter Beleglage hilft mehr als eine selbstsichere Vermutung.

5. Einmal prüfen und abschicken

Lies den Bericht aus der Perspektive einer Person, die den Fehler noch nicht gesehen hat. Prüfe Titel, Reihenfolge, Oberflächenbeschriftungen, Zahlen und erwartetes Ergebnis. Sind alle erwähnten Anhänge tatsächlich dabei? Kürze Wiederholungen, aber behalte die Voraussetzungen für die Reproduktion bei.

Weitere Anregungen findest du in unseren Beiträgen zum Schreiben von Dokumentation mit Spracheingabe und zum Überarbeiten von ersten Entwürfen.

TypeFree ist eine einfache Möglichkeit, Gesprochenes in bearbeitbaren Text umzuwandeln und schneller zu schreiben. Probiere es beim nächsten Fehlerbericht aus: Sprich den Ablauf ein, ergänze die exakten Angaben und erstelle eine klare Beschreibung, mit der andere weiterarbeiten können.