Bug-Triage ist der Prozess, neu gemeldete Defects zu bestätigen, einzustufen und zuzuweisen, damit die knappen Entwicklungsressourcen zuerst die Probleme mit der größten Wirkung beheben. Ein wirksamer Triage-Prozess garantiert zwei Dinge: jeder Defect wird innerhalb einer festen Zeit angesehen, und einmal angesehen, ist sein Schicksal entschieden (beheben, einplanen, herabstufen oder schließen).
Warum es Triage braucht
Teams ohne Triage-Mechanismus zeigen meist eine von zwei Pathologien:
- Laute-Stimme-Regel: Wer am lautesten beschwert, wird zuerst bedient; P0 und P2 stehen in derselben Schlange;
- Schwarzes Loch: Defects verstreuen sich in Chats, E-Mails und mündlichem Feedback, und ein guter Teil wurde nie von irgendjemandem „entschieden“.
Triage gibt allen Defects einen einheitlichen Eingang und einen Entscheidungspunkt: Jedes eingehende Element wird innerhalb von 24 Stunden verifiziert, mit Schweregrad und Priorität versehen und bekommt eine Zugehörigkeit.
Rollen im Triage
| Rolle |
Verantwortung |
| Triage-Moderation (meist QA Lead) |
Leitet das Triage-Meeting, hält die Queue bei null, treibt Entscheidungen an |
| QA / Tester |
Verifizieren Reproduzierbarkeit, ergänzen Reproduktionsschritte, vorläufige Einstufung |
| Dev Lead |
Bewertet technische Auswirkung, schätzt Behebungskosten, übernimmt Zuweisungen |
| Product Owner (PM/PO) |
Setzt die geschäftliche Priorität, entscheidet „beheben oder nicht“ |
Kleine Teams können QA Lead und PM in einer Person vereinen — aber beide Perspektiven, technisches und geschäftliches Urteil, müssen vertreten sein.
Der Standard-Triage-Fluss (5 Schritte)
1. Aufnehmen und deduplizieren
Reports aus allen Kanälen (internes Testing, Beta-Nutzer, Produktions-Feedback) landen im selben Register und werden nach Deduplizierung über „Modul + Symptom" zusammengeführt. Verstreute Eingänge sind die Wurzel des Triage-Versagens — der im Chat gemeldete Bug und der im Tool gemeldete Bug müssen in einer Tabelle landen.
2. Validieren
- Reproduzierbar? Die Schritte im Report einmal durchgehen;
- Nicht reproduzierbar: Umgebungsinformationen notieren und an den Melder zur Ergänzung zurückgeben — Teams, deren Reports Umgebungskontext mitbringen, bleiben hier kaum hängen (siehe unten);
- Kein Defect (erwartetes Verhalten / Nutzungsfrage): in eine Supportfrage oder Doku-Verbesserung umwandeln, schließen und dem Melder Bescheid geben.
3. Einstufen (Severity × Priority)
Schweregrad (technische Sicht) und Priorität (geschäftliche Sicht) sind zwei Dimensionen; nicht vermischen:
| Hohe Priorität |
Niedrige Priorität |
| Hoher Schweregrad |
Sofort beheben (Startseite bleibt weiß) |
Diesen Sprint beheben (eine Nischenfunktion stürzt ab, kein Workaround, aber kaum jemand gelangt dorthin) |
| Niedriger Schweregrad |
Bald beheben (verrutschter Login-Button, betrifft alle Nutzer) |
Ins Backlog (Tippfehler auf einer Randseite) |
Der häufige Fehler: „Schweregrad = Priorität" zu setzen. Dann verhungern dauerhaft all die Probleme, die „technisch nicht tödlich, geschäftlich peinlich" sind.
4. Zuweisen und einplanen
- P0: Hotfix oder Rollback am selben Tag, alle Beteiligten informieren;
- P2/P3: ins Product Backlog, wie üblich sortiert.
5. Zurückmelden und schließen
Nach dem Fix: den Melder (besonders externe Tester) zur Nachprüfung bitten → Verifikation bestanden → schließen und die Ursachenkategorie notieren (für die Retrospective-Statistik). Die Statusrückmeldung entscheidet direkt, ob externe Melder wieder melden.
Wie man das Triage-Meeting führt
- Frequenz: Teams mit schnellem Iterationstakt treffen sich täglich, 15–30 Minuten, nur neue Einträge; langsamere Takte 2–3 Mal pro Woche;
- Form: das Register-Board durchgehen, 3–5 Minuten pro Eintrag; was sich in 5 Minuten nicht entscheiden lässt, kommt auf „offen" und wird vor Feierabend im 1:1 geklärt;
- Disziplin: das Meeting trifft Entscheidungen, entwirft keine technischen Lösungen; nur Neuzugänge, nichts bereits Eingestuftes wird neu verhandelt.
Die Voraussetzung für schnelle Triage: Reports bringen Kontext mit
Die verschwenderischste Szene im Triage-Meeting: QA liest einen Report vor — „der Nutzer sagt, der Button tut nichts" — und alle fragen: welche Seite? welcher Browser? Fehler in der Console? Kannst du nochmal klicken? Ein Report, der 2 Minuten Einstufung hätte, wird zum 15-minütigen Detektivdrama.
Die Wurzel ist ein Report ohne Kontext. Der Vergleich:
| Information |
Manueller Report (Nutzer aus dem Gedächtnis) |
Automatisch erfasster Report |
| Reproduktionsschritte |
„Ich habe auf den Button geklickt und nichts ist passiert" |
Annotierter Screenshot/Recording zeigt Stelle und Aktion |
| Seiten-URL |
Oft fehlend oder falsch erinnert |
Automatisch beigefügt |
| Browser/Gerät |
Meist fehlend |
Automatisch beigefügt |
| Console-/Network-Fehler |
Praktisch unmöglich |
ERROR-Stacktraces und fehlgeschlagene Requests beigefügt |
Die rechte Spalte ist keine Fantasie — so arbeitet BugCapturer genau: Wenn Nutzer (auch völlig fachfremde Beta-Tester) Feedback einreichen, trägt der Bericht automatisch den annotierten Screenshot/das Recording, die URL, die Browserumgebung und Console-/Network-Fehler mit sich (siehe Diagnosefunktion). Im Triage-Meeting geht man das Register durch, 2 Minuten Einstufung pro Eintrag; der Anteil von „nicht reproduzierbar" bei der Validierung sinkt spürbar. Berichte werden automatisch in einen Slack / Microsoft Teams-Kanal gepusht — Deduplizierung und Statistik bekommen eine einzige Datenquelle.
Selbstcheck-Kennzahlen für die Triage-Qualität
| Kennzahl |
Gesunder Wert |
Bedeutung |
| Erste Reaktion auf einen Report |
< 24 h |
Von der Einreichung bis zur Triage-Entscheidung |
| „Offen"-Stau |
< 5 % |
Langlebige Offene bedeuten unklare Einstufungskriterien |
| Rate doppelter Reports |
sinkend |
Register und Dedup-Mechanismus wirken |
| Anzahl P0 |
sinkend |
Dauerhaft hoch bedeutet, der Qualitätssprozess stromaufwärts hinkt |
| Rückmeldequote der Melder |
hoch |
Zufriedenheit und Bindung externer Tester |
Diese Kennzahlen speisen auch die Sprint-Retrospective — siehe „Die Retrospective mit Daten stützen" im Sprint-Retrospective-Leitfaden.
FAQ
F: Was ist Defect Triage?
A: Der Entscheidungsprozess für neue Defects: validieren, deduplizieren, einstufen (Schweregrad × Priorität), zuweisen. Üblicherweise als Triage-Meeting in festem Takt, mit QA, Entwicklung und Produkt gemeinsam.
F: Bug-Triage vs. Bug-Tracking — was ist der Unterschied?
A: Tracking sind Werkzeuge und Mechanismus, um den Status von Defects zu erfassen und zu verfolgen; Triage ist der Prozess, pro Defect eine Behandlungsentscheidung zu fällen. Das Register ist das Tracking; die Triage ist die Entscheidungsschicht, die auf dem Register läuft.
F: Braucht ein kleines Team einen Triage-Prozess?
A: Ja, aber minimal: kein Meeting; der QA Lead geht täglich 15 feste Minuten durchs Register, stuft ein und weist zu. Zählt das Ergebnis — jeder Defect wurde ausdrücklich entschieden.
F: Der Melder ist nicht technisch — wie bleiben Reports verwendbar?
A: Von Meldern keine technischen Angaben verlangen; sie automatisch erfassen. Tools wie BugCapturer fügen bei der Einreichung URL, Umgebung und Console-/Network-Fehler bei, sodass auch Laien-Reports direkt triagiert werden können.
F: Wenn Schweregrad und Priorität streiten — wer gewinnt?
A: Die Priorität ist die endgültige Ausführungsreihenfolge, vom Product Owner im Triage-Meeting entschieden; der Schweregrad ist ein technischer Input für die Entscheidung, kein Ersatz.