Bug Reports effizient schreiben - Beste Praktiken für Fehlerberichte

Die Welt ist nicht perfekt und Software ist es auch nicht. Insbesondere dann nicht, wenn sie komplexer wird, mehrere Leute zusammenarbeiten und Anforderungen von außen das gewünschte Verhalten der Software beeinflussen. Menschen machen Fehler, die verwendeten Tools machen Fehler und die Kommunikation von Anforderungen ist auch nicht immer das Gelbe vom Ei. Natürlich versucht jeder immer, so wenig Fehler wie möglich zu produzieren. Aber es wird sich nie vermeiden lassen, dass sich der ein oder andere Bugs in die Software einschleicht.

Hat man einen Bug entdeckt oder ist davon betroffen, muss dieser idealerweise an irgendwen gemeldet werden. Doch wie macht man das eigentlich? Was muss man alles als Bug melden? Und was muss man alles in einen Bug Report aufnehmen? In diesem Artikel werden diese Fragen beantwortet.

Was ist ein Bug?

Die Frage “Was ist ein Bug?“ lässt sich aus zwei Perspektiven beantworten – einmal aus der formalen Sicht des ISTQB und aus der alltäglichen Sicht, die da draußen in der Welt auch verwendet wird. 

Definition “Bug” nach ISTQB

Das Wort “Bug” taucht im Glossar des ISTQB nicht auf. Stattdessen gibt es einige andere, ähnliche Definitionen. Da wäre zunächst der Fehlerzustand:

• Eine Unzulänglichkeit oder ein Mangel in einem Arbeitsergebnis, sodass es seine Anforderungen oder Spezifikationen nicht erfüllt oder seine beabsichtigte Verwendung beeinträchtigt. [ISTQB]

Eng verbunden mit dem Fehlerzustand ist die Grundursache:

• Die Ursache eines Fehlerzustands. Wenn man sie behebt, dann wird das Vorkommen der Fehlerart reduziert oder eliminiert. [ISTQB]

Diese beiden Begriffe sind natürlich sehr auf die Perspektive von Entwicklern und Product Ownern zugeschnitten. Aber auch aus der Sicht eines Anwenders lassen sich im Glossar passende Begriffe finden, wie etwa die Fehlerwirkung:

• Ein Ereignis, bei dem eine Komponente oder ein System seine Anforderungen im spezifizierten Rahmen nicht erfüllt. [ISTQB]

Auch die Fehlerauswirkung wird ein Nutzer wahrscheinlich zu sehen bekommen:

• Das physikalische oder funktionale Erscheinungsbild eines Fehlers. [ISTQB]

Bezeichnung “Bug” im Alltag

Die Preisfrage ist natürlich, welcher dieser ISTQB-Begriffe im alltäglichen Gebrauch mit Bug gemeint ist. Die Antwort darauf ist ganz einfach. Es sind alle:

• Fehlerzustand: Ein Entwickler hat vergessen, einen Button an das neue Design anzupassen? → Alle werden von einem Bug sprechen.
• Grundursache: Die Farbe des Buttons ist als rot statt grün definiert? → Alle werden von einem Bug sprechen.
• Fehlerwirkung: Der Nutzer hat einen grünen Button erwartet, aber sieht jetzt einen roten und ist traurig? → Er wird von einem Bug sprechen.
• Fehlerauswirkung: Der Button wird rot angezeigt? → Der Nutzer wird einen Bug dafür aufmachen.

Im Alltag ist ein Bug also einfach die Abweichung von einem erwarteten Zustand und beschreibt sowohl die Ursache, als auch die Auswirkung auf das beobachtbare Verhalten. Ob ein Entwickler diese Abweichung entdeckt oder ob sie erst von einem Nutzer beobachtet wird spielt dabei keine Rolle.

Warum ist Bug Tracking und Bug Reporting wichtig?

Komplexe Software lässt sich selten von einer Person komplett überblicken. Oft sind die Entwickler auch nicht vom Fach und wissen eventuell gar nicht, auf welche Art und Weise das Produkt überhaupt verwendet wird, sodass eine erwartungsgemäße Umsetzung von Use Cases stark davon abhängt, wie genau die Anforderungen abgesteckt sind. Umso wichtiger ist also, dass Feedback über Fehlverhalten auch bei den Entwicklern landet. Der Prozess erinnert insgesamt ein wenig an das erste Newtonsche Gesetz:

• Ein Körper verharrt im Zustand der Ruhe oder der gleichförmig geradlinigen Bewegung, sofern jener nicht durch einwirkende Kräfte zur Änderung seines Zustands gezwungen wird.

Auch Software verharrt typischerweise in dem Zustand, in dem sie sich befindet. Daran wird sich ohne Einwirkung von außen nichts ändern. Möchte man also eine gewünschte Änderung am Verhalten herbeiführen, muss man ein bisschen Kraft aufwenden und die Software durch einen Bug Report an die Entwickler zu einer Änderung des Zustands zwingen. Für große Änderungen braucht es viel Kraft und detaillierte Reports. Für kleine Änderungen tut es auch ein kleiner Report.

ℹ️ In fast allen gängigen Projektmanagement-Tools lassen sich Templates anlegen, damit alle Reports einheitlich und leicht auszufüllen sind.

So schreiben Sie einen effektiven Bug Report

Ein effektiver Bug Report (Fehlerbericht) erlaubt dem Empfänger, den Bug ohne weitere Nachfragen beim Verfasser zu verstehen und zu beseitigen. Dabei gilt immer, dass man so spezifisch wie möglich sein sollte. Kurz und knackig, kein langes “Herumgelabere”. Und ganz besonders wichtig: Sachlich bleiben. Wenn die Entwickler im Report als “unfähig” bezeichnet werden, wird der Bug Report im Backlog garantiert ganz am Ende landen.

In der Praxis haben sich die folgenden Bausteine als Bestandteile effektiver Bug Reports (Fehlerberichte) etabliert.

Prägnanter Titel

Der Titel sollte wie ein Betreff einer E-Mail direkt klar machen, um welchen Bereich der Anwendung es geht und was zu erreichen versucht wird:

• So kurz wie möglich, so lang wie nötig.
• Keine Nebensätze.
• Ganz objektiv ohne wertende Begriffe wie “leider”.

✅ Karte zeigt beim Verschieben keine Straßennahmen mehr an
❌ Wenn die Karte verschoben wird, verschwinden leider die Straßennamen

Idealerweise wird im Titel auch auf selbstverständliche Phrasen wie “funktioniert nicht” oder “kaputt” verzichtet. Man müsste den Bug nicht beschreiben, wenn nichts kaputt wäre.

Kurze Beschreibung

Eine kurze Beschreibung über das gewünschte und das beobachtete Verhalten ist extrem hilfreich, den Bug kontextuell einordnen zu können. Die Beschreibung sollte die folgenden Fragen beantworten:

• Wer hat den Bug beobachtet?
  • Wenn ich als Admin die Sprache ändere und anschließend die Karte auf der Startseite verschiebe, verschwinden die Straßennamen im angezeigten Bereich.
• Wo wurde der Bug beobachtet?
  • Wenn ich als Admin die Sprache ändere und anschließend die Karte auf der Startseite verschiebe, verschwinden die Straßennamen im angezeigten Bereich.
• Wann wird der Bug beobachtet?
  • Wenn ich als Admin die Sprache ändere und anschließend die Karte auf der Startseite verschiebe, verschwinden die Straßennamen im angezeigten Bereich.
• Was wird beobachtet?
  • Wenn ich als Admin die Sprache ändere und anschließend die Karte auf der Startseite verschiebe, verschwinden die Straßennamen im angezeigten Bereich.

Steps To Reproduce

Auch eine gute Beschreibung abstrahiert manchmal wichtige Schritte oder trifft Annahmen über das Wissen des Anwenders, die beim Entwickler dann fehlen, um den Bug reproduzieren und untersuchen zu können. Eine Anleitung, die Schritt für Schritt den Prozess bis hin zum Auftreten des Bugs beschreibt, ist der wichtigste Aspekt eines Bug Reports und sollte immer vorhanden sein:

1. Als Admin einloggen
2. In der Toolbar die Sprache von deutsch auf englisch ändern
3. Den Kartenausschnitt in eine beliebige Richtung verschieben

Die Schritte sollten dabei prinzipiell so feingranular aufgeführt sein, dass auch Personen, die die Anwendung noch nie gesehen haben, den Bug reproduzieren könnten. Ein bisschen technisches Verständnis darf natürlich vorausgesetzt werden. Einen Login muss man nicht immer über “klicke erst in das Input-Feld, dann tippe, dann klicke den Login-Button” beschreiben. Screenshots sind hier gerne gesehen, aber nicht zwingend erforderlich, sofern die Schritte selbst gut erklärt sind.

Erwartetes Ergebnis

Das eigentlich erwartete Ergebnis ist sehr wichtig, um zu verstehen, was der Verfasser des Reports überhaupt sehen wollte. Es liefert wichtigen Kontext für Entwickler beim Verständnis, was den Bug zu einem Bug macht. Hier ist eine kurze Beschreibung meist völlig ausreichend: Die Straßennamen sollten weiterhin zu sehen sein.

Tatsächliches Ergebnis

Das tatsächliche Ergebnis beschreibt, was statt des erwarteten Ergebnisses vorgefunden wurde. Hier sollte neben einer kurzen Beschreibung ein Screenshot oder ein kleines Video angehängt werden, das das Auftreten des Bugs “beweist”. Andernfalls ist für Entwickler je nach Bug nicht immer ersichtlich, wonach überhaupt Ausschau gehalten muss. Gerade bei Bugs, die nur unregelmäßig auftreten, ist ein Nachweis extrem wertvoll.

Weitere Informationen eines Bug Reports

Zusätzlich zum eigentlichen Fehlverhalten sind für die Entwickler oft weitere (technische) Informationen notwendig, um den Bug beheben zu können. Dazu gehören typischerweise:

• Umgebung (DEV, TEST, PROD, …)
• Betriebssystem
• Version der Anwendung
• Name/E-Mail des Verfassers, um Rückfragen stellen zu können
• Bei browserbasierten Anwendungen: der verwendete Browser
• Bei Anwendungen, die auf verschiedenen Geräten verwendet werden können: das verwendete Gerät
• Bei Anwendungen mit verfügbaren Logs: die aufgezeichneten Logs als Anhang

Wie Sie Bugs mithilfe von Testautomatisierung erkennen und beseitigen

Testautomatisierung hilft nicht nur Fehler frühzeitig zu erkennen, sondern kann diese in vielen Fällen auch automatisch melden. Moderne Testframeworks ermöglichen es, fehlgeschlagene Tests direkt in Bug-Tracking-Systemen zu erfassen. Typischerweise inklusive detaillierter Fehlermeldungen, Logs und Screenshots oder Videos. Sollte das Vertrauen in eine vollautomatische Fehlergenerierung fehlen, so sind diese automatisch generierten Logs und Screenshots dennoch eine enorme Erleichterung für Tester und Entwickler, da sie die Beschreibung der Fehler vereinfachen und somit schneller nachvollziehbar und reproduzierbar machen. Testautomatisierung reduziert also nicht nur die Fehlerquote, sondern optimiert auch den gesamten Bug-Reporting-Prozess.

Wir bei Qytera unterstützen Sie aktiv bei der Testautomatisierung - vereinbaren Sie jetzt Ihren Termin

Zusammenfassung: Effektive Bug Reports schreiben

Bugs sind ein Teil der Softwareentwicklung, ebenso wie die Meldung an die Entwickler oder Hersteller. Ein guter Fehlerbericht erleichtert nicht nur die Arbeit der Entwickler, sondern ermöglicht auch eine schnellere Fehlerbehebung und Verbesserung der Software. Klarheit, Präzision und Sachlichkeit sind dabei die wichtigsten Zutaten. Wer Bugs sauber dokumentiert, trägt nicht nur zur Qualitätssicherung bei, sondern spart sich und dem ganzen Team langfristig Zeit und Nerven.