“Software zu entwickeln ist ähnlich komplex, wie Autos zu bauen.

Für ihr Auto gibt es Crashtests, wer testet ihre Software?”

» Waidner IT Solutions | Mainz/Wiesbaden | +49 176 10042345
Home » Softwareentwicklung » Wie schreibt man den perfekten Bug-Report

Wie schreibt man den perfekten Bug-Report

Fehlerberichte oder Bug-Reports sind für viele ein Mysterium. Der Anwender macht sich die Mühe und schreibt eine Info an den Entwickler und wundert sich, warum nichts passiert, oder er nur Rückfragen bekommt. Der Entwickler wiederum erhält einen Fehlerbericht und versteht nicht, wo das Problem liegt und lässt es somit liegen. Vielen nicht-Programmierern ist einfach nicht klar, woraus ein Fehlerbericht bestehen muss, damit er schnell und zuverlässig bearbeitet werden kann.
Da ich dies in fast jedem Projekt einmal ansprechen muss, hier einmal die schriftliche Fassung zum Nachschlagen. Das Konzept greift für jede Programmiersprache, jedes Programm, praktisch jedes Softwareprojekt. Es ist egal, mit welchem Tool die Reports eingereicht werden (es kann auch eine einfache Email sein), die Grundbausteine sind immer gleich.

Die Basics

Wenn man dem Entwickler wirklich helfen will (und damit die Chancen drastisch erhöht, dass das Problem schnell bearbeitet wird), dann versucht man es erneut und merkt sich ganz genau die Schritte. Perfekt ist, wenn man Fehlermeldungen einfach durch einen Screenshot abfotografiert, dann geht keine Information verloren und der Entwickler sieht den Kontext. Dann kann man seinen Fehlerfall formulieren:

Ein aussagekräftiger Betreff

Der Problemempfänger wird zuerst nur den Betreff sehen und man kann davon ausgehen, dass schon danach gefiltert wird. Erfahrungsgemäß wird zuerst das bearbeitet, was man schnell versteht. Daher schon im Betreff darauf achten, dass

1) Das Fehlverhalten beschrieben wird und

2) Zeitpunkt und Ort des Auftretens erwähnt wird.

Schlecht: „Problem“

Gut: „Login zu Anwendung X funktioniert Montags nicht“

Zeitpunkt und User

Eine Information, die immer angegeben werden sollte, ist der Zeitpunkt (Datum + Uhrzeit) des Problems sowie der Anwender, bei dem es auftritt. Vielleicht läuft zur gegebenen Uhrzeit ein Backup und daher ist die Anwendung langsam, oder bestimmte Anwender haben andere Berechtigungen und sehen daher einige Eingabefelder nicht.

Eine Schritt-für-Schritt-Beschreibung

Ein Entwickler ist kein Anwender, weiß nicht, wie der Nutzer das Programm bedient und kann nicht raten, wie es zu einem Fehler kam. Daher immer darauf achten, dass der Kontext mitgegeben wird. Dies geschieht am einfachsten durch einen Schritt-für-Schritt-Beschreibung. Weiterhin kann man auf diese Art sehr gut prüfen, ob der Fehler immer auftritt, oder nur sporadisch.

Schlecht: „Ich bekomme manchmal bei der Anmeldung eine Fehlermeldung“

Gut: „Wenn man sich Montags in Anwendung X anmelden will, erscheint die Fehlermeldung blablabla. Ich habe User + Passwort in die korrekten Felder eingetragen und auf ‚login‘ geklickt. An anderen Wochentagen klappt es.

Screenshots

Wenn man die Möglichkeit hat, vom Fehlerzustand einen Screenshot anzufertigen, dann sollte man dies tun. Dabei sollte man beachten, dass man möglichst den kompletten Bildschirm abfotografiert und keine Auswahl trifft. Vielleicht sieht der Entwickler im Hintergrund noch etwas wichtiges, das man selbst nicht beachtet hat. Auf jeden Fall aber hilft ein kompletter Screenshot bei der Einordnung im Kontext und der Entwickler muss nicht suchen, wo im Programm das gezeigte Bild auftritt.

Schlecht: Nur einen kleinen Bildschirmausschnitt als Suchbild abfotografieren

Gut: Den kompletten Bildschirm abfotografieren. Damit erkennt man sofort, wo im Programm der Anwender sich befindet, was er sieht, wie hoch seine Bildschirmauflösung ist etc.

Tipp: Tools wie Monosnap können den Screenshot sogar mit Anmerkungen versehen.

Eine realistische Einschätzung der Dringlichkeit

Wenn man die obigen Punkte beachtet, dann hat man bereits sehr gute Chancen, dass das Problem zügig bearbeitet wird. Wenn man es jetzt noch schafft, eine realistische Einschätzung der Dringlichkeit des Problems zu formulieren, dann steigen die Chancen noch weiter (sogar, wenn die Dringlichkeit gering ist). Man kann sich sicher sein, dass sich ein Entwickler merkt, wo die guten und wo die schlechten Fehlerbeschreibungen herkommen. Genauso wird er sich merken, wer Dringlichkeit gut einschätzen kann und sich nicht übermäßig wichtig nimmt.

Schlecht: „DRINGEND !!!“ (am besten als alleinigen Betreff, die Anzahl der Ausrufezeichen multipliziert die Dringlichkeit der Aussage)

Gut: „Login zu Anwendung X funktioniert Montags nicht – Erstellen von Rechnungen nicht möglich“

Hinweis für die Techniker

Die bisher genannten Angaben sind ein Muss und sollten in einem Fehlerbericht immer auftauchen. Je mehr Felder ich in einem Fehlerbericht freischalte, je mehr ich von einem Anwender an Entscheidungen verlange, je tiefer ich nach IT-Wissen versuche zu grabe, desto fehlerhafter wird mein Bericht werden und desto unwilliger die Anwender, diesen einzureichen. Also lieber Softwareentwickler, Tester, Projektmanager – beschränkt euch aufs Wesentliche.