Bug-Tracking richtig aufsetzen: vom Report bis zum Fix

Gutes Bug-Tracking entscheidet sich nicht am Tool, sondern am Report. Je klarer eine Meldung reinkommt, desto schneller ist der Fehler behoben. Ein vager Hinweis wie „das Formular geht nicht“ löst eine Kette von Rückfragen aus, bevor überhaupt jemand mit der Reparatur beginnt. Ein guter Report dagegen lässt sich lesen, nachstellen und beheben – ohne dass der Melder noch einmal gefragt werden muss. Deshalb lohnt es sich, zuerst über den Report nachzudenken und erst danach über den Weg vom Report bis zum Fix.

Anatomie eines guten Bug-Reports

Ein brauchbarer Report beantwortet vier Fragen, bevor irgendjemand nachhaken muss. Er beschreibt, was passiert ist und was stattdessen hätte passieren sollen, wie man den Fehler nachstellt, welcher Bereich betroffen ist und unter welchen technischen Rahmenbedingungen er auftrat.

Ist und Soll

Der Kern jedes Reports ist der Unterschied zwischen Erwartung und Wirklichkeit. „Nach dem Klick auf Speichern erscheint eine leere Seite; erwartet war die Bestätigung“ ist eine vollständige Beschreibung. „Speichern kaputt“ ist keine. Erst der Kontrast zwischen Soll und Ist macht klar, worin der Fehler überhaupt besteht.

Reproduktionsschritte

Ein Fehler, der sich nicht nachstellen lässt, lässt sich kaum beheben. Deshalb gehört in jeden Report der Weg dorthin: welche Schritte in welcher Reihenfolge zum Problem führen. „Anmelden, Projekt öffnen, auf Neu klicken, Titel leer lassen, speichern“ ist wertvoller als jede Vermutung über die Ursache.

Betroffener Bereich und Technik-Daten

Wo trat der Fehler auf – auf welcher Seite, in welchem Teil der Anwendung? Und unter welchen Bedingungen: welcher Browser, welches Betriebssystem, welche Bildschirmgröße? Genau diese Angaben vergessen Melder am häufigsten, dabei entscheiden sie oft darüber, ob sich ein Fehler überhaupt reproduzieren lässt.

Kontext automatisch mitliefern

Man kann von niemandem erwarten, bei jeder Meldung Browserversion und Viewport-Größe herauszusuchen. Deshalb ist es besser, diese Daten gar nicht erst abzufragen, sondern automatisch zu erfassen. Ein Feedback-Widget auf der Seite nimmt Browser, Betriebssystem, Viewport und die Fehler aus der Browser-Konsole von selbst auf und hängt sie an die Meldung.

Dazu kommt der Screenshot. Der Melder markiert direkt im Bild, was nicht stimmt – mit Pfeil, Rechteck oder Stift, bei Bedarf mit Zoom, und Bilder lassen sich per Strg+V einfügen. Aus „oben rechts stimmt was nicht“ wird so eine eindeutige Stelle. Die typische Rückfrage „In welchem Browser war das?“ entfällt komplett, weil die Antwort schon an der Meldung hängt.

Priorisieren statt sammeln

Ein Bugtracker, der nur sammelt, wird schnell zur Halde. Nicht jeder Fehler ist gleich dringend, und die Reihenfolge des Eingangs sagt nichts über die Wichtigkeit. Vergib die Priorität danach, wie stark ein Fehler Nutzer blockiert: Trifft es viele Nutzer? Steht ein zentraler Ablauf still, oder gibt es einen Umweg? Ein Absturz beim Bezahlen wiegt schwerer als ein schiefer Abstand im Footer, auch wenn Letzterer zuerst gemeldet wurde. So arbeitet ihr an dem, was wirklich weh tut, statt die Liste stur von oben nach unten abzuarbeiten – ein Ansatz, der sich vor allem für Software-Teams auszahlt.

Der Status-Fluss: vom Report bis zum Fix

Jeder Bug durchläuft dieselben Stationen, und ein sichtbarer Status sagt jedem im Team ohne Nachfrage, wo eine Meldung gerade steht.

• Offen: Die Meldung ist geprüft und priorisiert, aber noch nicht begonnen.
• In Arbeit: Jemand hat sich der Sache angenommen und arbeitet daran.
• Review: Die Änderung ist fertig und wird gegengeprüft.
• Erledigt: Der Fehler ist behoben und der Vorgang dokumentiert.

Board und Liste zeigen dieselben Aufgaben in zwei Ansichten. Im Board siehst du den Fluss über die Spalten auf einen Blick, in der Liste arbeitest du viele Vorgänge schnell ab und änderst Status oder Priorität inline. Was du in der einen Ansicht änderst, steht sofort in der anderen.

Blocker früh sichtbar machen

Manche Bugs lassen sich erst beheben, wenn vorher etwas anderes erledigt ist. Diese Abhängigkeit gehört an die Aufgabe, nicht in einen Kommentar oder in einen Kopf. Kann ISS-481 erst weiter, nachdem ISS-462 erledigt ist, verknüpfst du beide als Blocker-Beziehung. Dann siehst du an beiden Aufgaben, was zuerst fertig sein muss, und kein Fehler bleibt unbemerkt liegen, nur weil er still auf etwas anderes wartet. Wie sich solche Abhängigkeiten übersichtlich führen lassen, zeigt der Beitrag Blocker sichtbar machen.

Doppelmeldungen handhaben

Beliebte Fehler werden mehrfach gemeldet, oft mit leicht anderen Worten. Das ist kein Ärgernis, sondern ein Signal: Je öfter etwas reinkommt, desto mehr Nutzer trifft es. Prüf im Eingang, ob es zu einer neuen Meldung schon eine Aufgabe gibt. Wenn ja, schließ die Dublette und halt die Häufung an der ursprünglichen Aufgabe fest, statt fünf parallele Vorgänge zum selben Bug zu führen. So bleibt die Übersicht erhalten, und die Wirkung des Fehlers wird sogar deutlicher.

Häufige Fehler

• Sammeln statt priorisieren: Ein Bugtracker ohne echte Prioritäten wird zur Halde, in der das Wichtige untergeht.
• Vage Reports akzeptieren: „Geht nicht“ ohne Ist, Soll und Bereich kostet mehr Zeit in Rückfragen als in der Reparatur.
• Kein Reproduktionsweg: Ein Fehler, den niemand nachstellen kann, lässt sich kaum beheben.
• Blocker nur im Kopf: Abhängigkeiten, die nicht an der Aufgabe stehen, fallen erst auf, wenn es zu spät ist.
• Duplikate parallel führen: Fünf Vorgänge zum selben Bug zersplittern die Übersicht und verschleiern, wie oft er auftritt.

Checkliste für Melder

• Was ist passiert und was hätte passieren sollen?
• Welche Schritte führen zum Fehler, in welcher Reihenfolge?
• Auf welcher Seite oder in welchem Bereich tritt er auf?
• Screenshot markieren und die Stelle eindeutig kennzeichnen.
• Technik-Daten mitliefern – am einfachsten automatisch über das Widget.
• Vor dem Absenden kurz prüfen, ob der Fehler vielleicht schon gemeldet ist.