Ablaufdiagramm Bug-Triage-Prozess (Fehlermanagement)
Ablaufdiagramm für die Bug-Triage: Fehlermeldung erfassen, reproduzieren, Duplikate prüfen, Schweregrad und Priorität vergeben, eskalieren, beheben, verifizieren und ausrollen.
So funktioniert es
Benennen Sie die Bahnen nach Ihren Rollen
Ersetzen Sie Melder, Support, Triage-Lead, Entwicklung und QA durch Ihre echten Funktionen. Kleine Teams führen Support und Triage häufig in einer Bahn zusammen, und ohne eigene QA übernimmt die Verifizierung meist eine zweite Entwicklerin. Nutzen Sie eine Bahn je Entscheidungsträger statt je Person, sonst passt das Diagramm beim nächsten Stellenwechsel nicht mehr.
Schreiben Sie Ihre Definitionen von Schweregrad und Priorität an den Triage-Schritt
Der Schweregrad beschreibt die Auswirkung im Fehlerfall, die Priorität den Zeitpunkt der Bearbeitung. Definieren Sie jede Stufe mit einem konkreten Beispiel, etwa Datenverlust oder ein blockierter Checkout ganz oben und eine kosmetische Verschiebung ganz unten. Ohne Beispiele kommt jede Meldung auf der höchsten Stufe an, und das Feld trägt keine Information mehr.
Setzen Sie die Eskalationsschwelle
Ersetzen Sie die allgemeine Entscheidung „Kritisch oder Produktion ausgefallen?“ durch Ihren echten Auslöser: betroffene Kunden, ein blockierter Umsatzpfad, gefährdete Daten. Benennen Sie, wer einen Incident ausrufen darf und wo der Incident-Prozess liegt — die Triage übergibt an dieser Stelle, während der Fehlerdatensatz für die dauerhafte Behebung offen bleibt.
Legen Sie fest, wie lange die Rückfrageschleife läuft
Die Entscheidung „Melder antwortet fristgerecht?“ braucht eine benannte Wartezeit und in der Regel eine Erinnerung. Schreiben Sie die Zahl an den Schritt. Ohne sie bleiben Meldungen, die nie reproduzierbar waren, unbegrenzt offen, und das Backlog bildet die reale Arbeit nicht mehr ab.
Klären Sie, was Verifizierung bedeutet und wohin eine Wiedereröffnung führt
Halten Sie fest, ob die QA gegen die ursprünglichen Schritte des Melders, gegen eine Regressionssuite oder gegen beides prüft. Diese Vorlage führt eine nicht bestandene Verifizierung auf demselben Datensatz zurück in die Entwicklung, damit die Historie an einem Ort bleibt. Führen Sie sie stattdessen in die Triage zurück, wenn ein wiedereröffneter Fehler neu priorisiert und nicht sofort wieder aufgenommen werden soll.
Veröffentlichen Sie das Diagramm und halten Sie eine gültige Fassung
Legen Sie das Diagramm neben das Formular für Fehlermeldungen und in das Runbook der Rufbereitschaft, holen Sie die Freigabe von Support, Entwicklung und QA ein und bewahren Sie die früheren Fassungen auf, damit sichtbar bleibt, wann sich der Prozess geändert hat. Sehen Sie es sich nach jedem Fehler wieder an, dessen Behebung deutlich zu lange gedauert hat, und korrigieren Sie den Schritt, an dem es hakte.
Häufig gestellte Fragen
Aus welchen Phasen besteht ein Bug-Triage-Prozess?
In den meisten Teams aus fünf. Aufnahme, in der die Meldung mit ausreichend Details erfasst wird. Reproduktion, in der der Support bestätigt, dass der Fehler existiert und kein Konfigurations- oder Bedienfehler ist. Triage, in der Duplikate verknüpft und Schweregrad, Priorität und ein zuständiges Team vergeben werden. Behebung, also Entwicklung und Code-Review. Verifizierung, in der die QA die Behebung gegen die ursprüngliche Meldung prüft, bevor ausgerollt und der Melder informiert wird. Das Diagramm oben nutzt genau diese fünf als Phasenspalten, wobei Reproduktion und Triage die Entscheidungen tragen, die die eigentliche Arbeit leisten.
Was ist der Unterschied zwischen Schweregrad und Priorität?
Der Schweregrad beschreibt die Auswirkung des Fehlers: Datenverlust, ein blockierter Ablauf, ein kosmetisches Problem. Die Priorität beschreibt, wann daran gearbeitet wird. Beide beantworten verschiedene Fragen und sollten getrennte Felder bleiben. Ein Tippfehler in einem veröffentlichten Preis hat niedrigen Schweregrad und hohe Priorität; ein Absturz in einer Funktion, die zwei Kunden nutzen, kann hohen Schweregrad und niedrige Priorität haben. Beides in ein Feld zusammenzuziehen ist der häufigste Grund, warum ein Triage-Prozess sein Vertrauen verliert — weil am Ende alles ganz oben landet.
Wie oft sollte Bug-Triage stattfinden, und wer muss dabei sein?
Ein kurzer wiederkehrender Durchgang über alles, was seit dem letzten Mal aufgelaufen ist: täglich bei einem laufenden Endkundenprodukt, zweimal pro Woche bei langsameren Releasezyklen. Drei Rollen reichen meist für die Entscheidung: jemand aus dem Support, der die Kundenwirkung beurteilen kann, ein Triage-Lead, der Schweregrad und Priorität verantwortet, und ein Entwicklungs-Lead, der weiß, welches Team den Code besitzt. Alles Kritische oder ein Produktionsausfall darf nicht auf den Termin warten — deshalb eskaliert dieses Diagramm solche Fälle sofort als Incident, statt sie einzureihen.
Was soll mit einem Fehler geschehen, der sich nicht reproduzieren lässt?
Schließen — aber erst nach einer ausdrücklichen Schleife. Fragen Sie einmal nach den fehlenden Angaben (Build, Umgebung, exakte Schritte, eine Bildschirmaufnahme), erinnern Sie innerhalb einer festgelegten Wartezeit und schließen Sie dann als nicht reproduzierbar, mit dokumentierter Begründung und der offenen Einladung, bei erneutem Auftreten wieder zu öffnen. Diese Vorlage zeichnet die Schleife als Entscheidung in der Melder-Bahn, statt sie dem Einzelfallgefühl zu überlassen — denn dauerhaft offene, nicht reproduzierbare Meldungen sind es, die aus einem Backlog eine Liste machen, die niemand mehr liest.