Jeder, der Software für die Allgemeinheit geschrieben hat, wird wahrscheinlich schon einmal einen schlechten Fehlerbericht erhalten haben. Nichts sagende Berichte („Es geht nicht!“), Berichte, die keinen Sinn ergeben, Berichte, die einem nicht genug Informationen geben, Berichte, die einem falsche Informationen geben. Berichte von Problemen, die sich schließlich als Fehlbedienung durch den Benutzer herausstellen, oder bei denen das Problem bei einem anderen Programm liegt oder die auf Netzwerkfehler zurückzuführen sind.
So schreibt Simon Tatham bereits 1999 in seinem Artikel zum Thema Fehlerberichte richtig melden und versucht sich an der leidlichen Aufgabe, die Kommunikation zwischen versiertem Dienstleister und vermeintlich dummen Anwender zu optimieren bzw. Richtlinien dafür zu erstellen.
Mit diesem Beitrag stelle ich mich in die Reihe derer Programmierer, die die Notwendigkeit einer guten Fehlerbericherstattung kennengelernt haben und hoffe, dass hier der ein oder andere Hinweis hilfreich für andere Entwickler, Projektleiter & Anwender ist.
Theory of the DAU
Kann es denn sein, dass der User nur aus plumper Faulheit viertelgare, emotional aufgeladene Halbsätze zu eigentlich hervorragend funktionierender, schöner Software abgibt? Oder steckt doch noch mehr dahinter? Wie verhält man sich als Dienstleister zum DAU (= Dümmster anzunehmender User)?
Fehlerberichte existieren seit Menschengedenken. Und involvieren in der Grundsache immer zwei oder mehr Personen, die – wenn nicht gerade stoßgebetsartige Reklamationen zu verpfuschten Leben und Ungerechtigkeiten aller Art die Natur des ‚Bug Reports‘ sind – ganz irdisch denken & handeln. Deshalb ist von den Beteiligten auch nicht Übermenschliches zu erwarten und man muss sich als „der Klügere“ in der Gleichung darum bemühen, dass der/die Andere(n) es leicht gemacht bekommen, fehlerhaftes Verhalten aufzuzeigen.
Jede Industrie und jede Branche hat Ihre eigenen Erfahrungen mit Fehlerberichten gesammelt und – manchmal mehr und manchmal weniger gut – Ihre Produkte und/oder den Umgang mit Fehlern optimiert. Demzufolge ist die Situation des Programmierers auch keine Neue sondern höchstens eine andere, diffizilere.
A brief history of failure
Es gibt „Fehler“, die unmittelbar ersichtlich sind und im Einvernehmen festgestellt werden können (ein fauler Apfel, ein Rechtschreib- oder Rechenfehler, ein Rohrbruch, …). Solche Fehler haben den großen Vorteil, dass keine Diskussion über das schadhafte Produkt entstehen – entweder/oder, ganz oder kaputt, richtig oder falsch. Wie es zu dem Fehler kam, steht auf einem anderen Blatt geschrieben.
Das ist dann aber meist auch nicht so wichtig, denn entweder wird die Fehlerursache einfach ausgeblendet (Apfel wird weggeschmissen / gehe einen neuen Apfel kaufen), der Grund für den Fehler ist sekundär (die Wohnung steht verdammt noch mal unter Wasser!) oder die Ursache ist insofern unmittelbar ersichtlich, weil fixe Regeln und Vorgaben existieren, die das ‚korrekte‘ Produkt kennzeichnen (2+2 = 5? Ich kann wohl nicht richtig rechnen…).
Mit zunehmender (technischer) Komplexität und einer Mehrzahl von Anwendungsszenarien bleibt die Klarheit der Fehleridentifikation leider auf der Strecke. Und genau das ist es, was die Herausforderung des Bug Reportings im Webdesign bzw. im Software-Bereich ausmacht:
- technisch vermittelte Interaktion, kein genuin persönlicher Austausch möglich
- Kenntnisstand der verschiedenen Anwender variiert stark
- Vielzahl verschiedener Systemkonfigurationen, von denen aus das Produkt abgerufen wird
- fehlende Richtlinien / Vorgaben zur Fehlermeldung
Natürlich kann man hier noch ‚granularer‘ werden, klar sein dürfte aber: In wenigen Anwendungsfelder ist die Relevanz einer produktiven Fehlermeldung ähnlich hoch wie im Webdesign bzw. der Programmierung von User-Applikationen. Genug aber der Theorie – wie schreibe ich denn jetzt einen guten Bug Report?
Fehlermeldungen richtig verfassen
In seinem Quality-Assurance-Blog beschreibt Vijay Shinde bereits sehr gut, was die Anforderungen an einen guten Bug Report sind. In Kürze:
Reproduzierbarkeit
Hieraus leitet sich (eigentlich) das Gros der übrigen Anforderungen ab: Der Fehler muss wiederholbar sein. Wenn er das nämlich ist, dann ist sichergestellt, dass es sich auch wirklich um einen Programmierungsfehler handelt und nicht um einen Anwendungsfehler. Das wiederum setzt aber auch den nächsten Punkt voraus:
Genauigkeit / Spezifität
Nur ein umfangreicher, dabei aber präziser Fehlerbericht versetzt den Programmierer in die Lage, den Fehler zu isolieren und (siehe oben) zu reproduzieren. Hierzu gehören neben Angaben zum Zeitpunkt des Errors (Stichwort: Log-Einsicht) auch solche wie die Browser- und OS-Version sowie die exakte Seite/URL, auf der der Fehler aufgetreten ist. Hinzu kommen sinnvolle Angaben zur Nutzung, d.h. welche Funktion sollte durchgeführt werden und was ist stattdessen passiert. Man sollte dabei möglichst vermeiden, mehrere Fehler unter einen Hut bringen zu wollen und eher einzelne Berichte erstellen.
Bonus: Priorisierung & Pre-Evaluation
Falls sich ein Support-Mitarbeiter im Bug-Reporting-Prozess befindet und als Schnittstelle zwischen End-User und Entwickler fungiert, dann kann dieser den Bug-Report nicht nur kontrollieren sondern auch um einige zusätzliche Informationen anreichern: Welcher Art ist der Fehler – betrifft dieser die Funktion der Website oder einen Design-Aspekt? Handelt es sich eher um eine Anregung / einen Verbesserungsvorschlag oder doch um eine Funktionsstörung? Dementsprechend kann man auch Prioritäten vergeben und signalisieren, welcher Fehlerbehebung Vorrang gewährt werden soll und welches Element auch in 3 Tagen noch angepackt werden kann.
Automatisierung des Bug-Reportings
Auch wenn man jetzt schon die wichtigsten Inhalte eines Fehlerreports kennt, dann bedarf es für die konkrete Anwendung immer noch einiger Schritte: Welche Fragen soll ich formulieren? Wie übermittle ich diese dem Kunden? Wie genau sieht eine Anleitung aus, die einen guten Fehlerbericht produziert?
Wie immer gibt es auch hier verschiedene Herangehensweisen, von denen ich ein paar vorstellen möchte:
1. Bugdigger – das Tool-Kit fürs Bugreporting
Meines Erachtens eine hervorragende Software, die eigentlich alle Aspekte eines effizienten & produktiven Fehlerberichts beinhaltet. Die Automatisierung der Datenerhebung und die „Screenshot-Scribble-Funktion“ machen den Bugdigger zum praktischen Toolset wenn es darum geht, einfach und schnell Reports auszutauschen. Zudem wird die Anbindung an Anwendungen wie Basecamp oder den Pivotal Tracker ermöglicht, was die Arbeitsabläufe weiter vereinfachen kann.
Die Preisstaffelung gestaltet sich ebenfalls sehr fair – ab 19,- USD / Monat erhält man einen absolut ausreichenden Leistungsumfang. Das große Manko bei einem Tool wie dem Bugdigger ist aber, dass viele Endnutzer mit der Verwendung überfordert sein dürften, da man sich zuerst ein Browser-Plugin installieren muss. Das schränkt dann auch die Kompatibilität ein und reduziert den potentiellen User-Kreis auf erfahrene Anwender bzw. die Verwendung im internen Entwicklungsteam.
UPDATE: Bugdigger gibt es inzwischen nicht mehr…
2. Semi-Automatisches Reporting via Fragebogen & Online-Tool
Alternativ kann man sich auch einfach einen standardisierten Fragebogen entwerfen, der es dann per Copy&Paste zum User schafft. Durch die Verwendung eines Online-Tools wie SupportDetails kann man dem Benutzer dann auch relativ barrierefrei ermöglichen, die gröbsten / relevantesten Details ausfindig zu machen – denn kaum jeder weiß, wo genau man Typ und Versionsnummer seines Betriebssystems nachschlagen kann…
3. Online-Fragebogen via GravityForms
Ich bin Fan von GravityForms – das Formular-Management-Tool für WordPress ist in Umfang & Anwendungsmöglichkeiten unübertroffen und der Support ist erstklassig. Adaptiert man nun den (fast schon analogen) Email-Fragebogen als Online-Formular & kombiniert GravityForms mit dem (kostenpflichtigen) Plugin infoGeniuz, dann erhält man sämtliche Systeminformationen zusammen mit der Fehlerbeschreibung frei Haus.
(* Aff-Links)
Schreiben Sie einen Kommentar