Leitfaden: Wie schreibe ich einen guten Fehlerreport?
Jede Software hat Fehler. Wir erkennen sie oft erst im Laufe der Nutzung oder in dedizierten Testing-Phasen. Die Abteilungen „Testing“ und die Abteilung „Entwicklung“ stehen dabei vor der besonderen Herausforderung, die gleiche Sprache zu sprechen.
Dabei spielt ein Instrument eine zentrale Rolle: der Fehlerreport, also die Meldung eines Fehlers oder Bugs, der innerhalb der Software auftritt.
Dieser Leitfaden soll dabei helfen, dass sich KundIn, User, TesterIn und Developer besser verstehen, wenn es darum geht, gemeinsam Probleme an Website oder App zu lösen.
Art: Makel, Unbequemlichkeit, Unzumutbarkeit?
Fehlertypen sind zahlreich. Ein verrutschter Pixel ist kein Bug. Eine unerreichbare Seite hingegen keine Lappalie.
Fassen Sie kurz zusammen, welchen Bereich der Bug betrifft, welche Nutzergruppe und wie kritisch das ganze in Ihren Augen ist.
Wenn Sie Dinge geändert haben möchten, die schon länger so sind, ist das meist ein Change Request, kein Bugfix. Das kostet oft etwas, da das Produkt ja zusätzliche Funktionen erhält. Das kann sich lohnen, muss aber nicht.
An den Report können Sie bereits ein entsprechendes Label heften um die Einordnung und Priorisierung zu vereinfachen. Beispielsweise in dieser Form:
- Show Stopper / Critical: Alles, was definitiv so nicht live gehen oder bleiben kann. Fixing asapst erwünscht.
- Feature Request: Alles, was schön wäre, aber nicht im eigentlichen Umfang enthalten oder anders abgesprochen war. Hier kann nach Absprache unterschiedlich mit umgegangen werden.
- Minor Case: Unschön, aber aushaltbar. Behebung wenn es die Zeit zulässt, keine Dringlichkeit.
Umfang: Eins nach dem anderen
Pro Sinnabschnitt - das kann ein Absatz, ein Ticket, eine E-Mail, ein Forenbeitrag o.ä. sein - widmen Sie sich nur einem Thema auf einmal. So lässt sich fokussierter Arbeiten und später besser ein Häkchen dran machen, ohne dass andere verschachtelte Themen hinten runter fallen.
Formulierung: Soll / Ist
Was für die eine absolut glasklar ist, erschließt sich dem anderen erst nach mühevoller Recherche. Eine Hauptursache dafür ist die Verknappung von Beschreibungen. Wie zum Beispiel würden Sie folgende Formulierung verstehen:
Bild unter Text
Die grammatische Verkürzung lässt zwei Möglichkeiten zu: Entweder ist das Bild fälschlicherweise unter dem Text und genau das soll geändert werden oder aber das Bild befindet sich nicht in der richtigen Position und sollte unter dem Text erscheinen.
Um solche Unklarheiten zu vermeiden, hat sich die "wie soll etwas sein?"-Strategie als wirksam herausgestellt. Formulieren Sie Reports immer mit dieser Frage im Hinterkopf. Aus dem oberen Beispiel wird dann:
Bild sollte unter Text stehen
Nur wenige Worte mehr, aber deutlich verbesserte Verständlichkeit.
Umgebung: Browser, Betriebssystem, Versionen
Gerade bei Webapplikationen und Webseiten gibt es große Varianzen zwischen den Systemen, auf denen sie angewendet werden. Liefern Sie daher immer zumindest Browser- und Betriebssystemnamen bei einem Report mit – und wenn möglich, auch Versionsnummern für beide Punkte.
Auch wenn Ihnen in einem bestimmten Browser mehrere Bugs auf einmal auffallen, so gehören die nicht in denselben Sinnabschnitt – für einen anderen Fehler im selben Kontext schreiben Sie einen neuen Report. Entwickler fixen nämlich nicht Browser für Browser, sondern Bug für Bug. Also nicht: "Browser XY zeigt folgende Bugs:..." , sondern: "Dieser Bug tritt in folgenden Browsern auf:...".
Nicht suchen lassen, Weg weisen: Wo ist der Bug genau?
Neben wichtigen Infos wie Browser- und Systemumgebung verkürzt es den Dialog ungemein, wenn Sie genau beschreiben, auf welcher Seite (URL) und/und bei welchem Inhalt der Fehler auftritt.
Liefern Sie daher direkt Deep-Links („tiefe“ Adressen, die sofort zum Ort des Geschehens führen) mit, falls möglich. Wenn ein Redaktionssytem im Spiel ist und der Inhalt dort auch eine Rolle spielt, gilt das auch für diesen Bereich.
Rekonstruktion: Schritt für Schritt
Manche Fehler sind komplexer als sie vermuten lassen. Der technische Support versucht stets, den Fehler erst einmal zu reproduzieren.
Dafür ist es oft wichtig, ziemlich haargenau zu wissen, welche Schritte getan wurden, um den Fehler zu sehen, so banal sie auch zu sein scheinen.
Welche Adresse haben Sie aufgerufen, wo haben Sie in welcher Reihenfolge geklickt? Was ist dann passiert und wie ging es weiter?
Liefern Sie eine knappe aber aussagekräftige Schritt-für-Schritt-Reproduktionsanleitung. Die kann zum Beispiel so aussehen:
- Öffne im Browser URL www.meinedomain.de
- Klicke auf Navigationspunkt "Veranstaltungen"
- Seite „Veranstaltung“ öffnet sich
- Klicke bei einer beliebigen Veranstaltung auf "Ticket kaufen"
- Bekomme in einem kleinen Fenster die Fehlermeldung „access denied", klicke auf OK
- Lande auf der Startseite
Screenshots und Screencaptures: soviel wie nötig, so wenig wie möglich
Manchmal reichen Kontextbeschreibung und Reproduktions-Anleitung nicht aus. Ein Bild sagt bekanntlich mehr als tausend Worte. Es sagt aber oft auch zu viel irrelevantes.
Wenn Sie meinen, dass Screenshots die Sache verdeutlichen, hängen Sie sie an den Report an. Falls möglich, markieren Sie die Stelle im Screenshot, um die es geht.
Wenn es hart auf hart kommt, können auch Screencaptures, also kleine Videoaufnahmen helfen.
Freundlichkeit vor Dringlichkeit
Natürlich tun Fehler im eigenen Produkt weh. Und doch werden sie immer da sein: die Bugs, selbst wenn Sie oder Ihr Dienstleister sie nicht gefunden haben.
Gelassenheit und Freundlichkeit sind das oberste Gebot. Entwickler ärgern sich naturgemäß sehr über Fehler im Code und geben ihr Bestes, die Auswirkungen klein zu halten. Es hilft aber niemandem, sich gegenseitig anzugiften oder Schuldige zu suchen.
Manchmal müssen sich auch Prioritäten einer technischen Pragmatik beugen. Ein Fehler im Kopfbereich lässt sich vielleicht erst beheben wenn eine grundsätzliche Problematik mit den Bildern ausgeräumt ist. Auch wenn sie lieber erst den Header gefixt wissen möchten, berücksichtigen Sie, dass man keine Socken anziehen kann, wenn man schon in Schuhen steckt.
Warum das alles wichtig ist
Weil Sie möchten, dass Fehler behoben werden, gründlich, schnell und ohne einen unnötigen Overhead an Arbeit zu erzeugen. Das tut Ihnen, dem Budget, den Dienstleistenden und nicht zuletzt dem Produkt gut.
Außerdem möchten sich alle Beteiligten auch morgen noch auf Augenhöhe und aufrichtig freundlich begegnen können. :)