Bug-Triage ist die Arbeit zwischen „ein Bericht ist eingegangen“ und „jemand behebt ihn“. Die meisten Teams sind beim Entscheiden nicht langsam. Langsam sind sie bei allem drumherum.
Sieh dir einen normalen Durchgang an. Bericht öffnen. Lesen. Zurück zur Liste. Die Stelle wiederfinden. Den nächsten öffnen. Wieder zurück. Jede Entscheidung dauert Sekunden, die Navigation frisst den Rest der zehn Minuten. Schlimmer noch: Jeder Hin- und Rückweg ist ein kleiner Kontextwechsel, und genug davon machen die Triage zu der lästigen Pflicht, die so lange aufgeschoben wird, bis der Backlog unlesbar ist.
Dieser Workflow schafft die Navigation ab, statt von irgendwem zu verlangen, schneller zu denken.
Was Bug-Triage eigentlich ist
Triage stellt jedem eingehenden Bericht drei Fragen:
Ist das neu? Oder ist es der vierzigste Bericht zu etwas, wofür du schon eine Aufgabe hast?
Ist es echt? Reproduzierbar oder durch Belege gestützt, die eindeutig genug sind, um danach zu handeln.
Wie dringend ist es? Im Vergleich zu allem anderen, was gerade offen ist, nicht für sich allein.
Alles andere – zuweisen, Labels vergeben, Reproduktionsschritte aufschreiben, die für diesen Teil des Codes zuständige Person dazuholen – folgt aus diesen drei Antworten. Eine Triage-Session, die Antworten liefert, funktioniert. Eine, die eine längere Liste mit Dingen für später liefert, funktioniert nicht.
Der Hin- und Rückweg ist der eigentliche Kostenfaktor
Ein Bericht lohnt das Lesen nur im Kontext: die Beschreibung, die Console-Fehler drumherum, die fehlgeschlagene Anfrage, Browser und Viewport, was die Person in den Sekunden vor dem Fehler angeklickt hat. Dieser Kontext liegt in einer Detailansicht.
Also wird die Schleife zu Liste, Detail, Liste, Detail. Jeder Sprung lädt eine Seite neu, verliert deine Scrollposition und vergisst, bei welchem Eintrag du warst. Zehn Berichte sind zwanzig Seitenwechsel, und ab dem sechsten liest du nicht mehr sorgfältig.
Die Lösung ist keine schnellere Seite, sondern die Liste gar nicht erst zu verlassen.
Eine Spalte nach der anderen
Bevor du irgendetwas öffnest, grenz das Board auf eine einzige Warteschlange ein. In BugDump heißt das: nach einer Priorität, einem Browser oder einem Suchbegriff filtern und dann eine einzelne Spalte von oben nach unten abarbeiten.
Dabei passieren zwei Dinge. Die Warteschlange bekommt ein klares Ende, und genau das macht eine Session abschließbar statt endlos. Und jede Aufgabe darin lässt sich mit der vorherigen vergleichen, also ist relative Priorität kein Ratespiel mehr. Du wägst nicht mehr im selben Atemzug einen kritischen Checkout-Bug gegen einen Tippfehler im Text ab.
Eine Spalte entspricht auch der Art, wie das Auge ein Board ohnehin liest. Quer über Spalten zu arbeiten heißt, sich ständig neu zu orientieren.
Durchgehen statt navigieren
Öffne die erste Karte. Statt einer neuen Seite öffnet sich die Aufgabe in einem Panel neben dem Board: Beschreibung, jeder angehängte Bericht mit Console- und Netzwerk-Logs, Kommentare und die Steuerelemente für Status, Zuständigkeit und Priorität.
Dann lass die Maus los. J springt zur nächsten Aufgabe in dieser Spalte. K geht zurück. Lesen, Priorität setzen, zuweisen, verschieben, J drücken. Das Board lädt nie neu und verliert nie seine Position, also schrumpft die Schleife auf einen Tastendruck zwischen zwei Entscheidungen.
Zwei Details sind wichtiger, als sie klingen:
Das Durchgehen bleibt in der Spalte, in der du angefangen hast. Es stoppt an den Enden, statt wieder von vorn zu beginnen oder in die nächste Spalte zu rutschen. Eine Spalte fertig zu haben ist also ein echtes Ereignis und nicht etwas, das dir drei Aufgaben später auffällt.
Das Durchgehen folgt den Filtern. Filterst du auf kritische Bugs, besucht „Nächste Aufgabe“ nur kritische Bugs. Die Warteschlange, die du festgelegt hast, ist die, die du abläufst.
Die Shortcuts kommen dir beim Tippen auch nicht in die Quere: Ein j in einem Kommentar bleibt ein j in einem Kommentar.
Eindeutige Entscheidungen gebündelt treffen
Manche Triage braucht gar kein Lesen. Ein schlechtes Deploy erzeugt dreißig Berichte zum selben Fehler. Eine Spam-Welle erzeugt zwanzig Berichte über nichts.
Geh die nicht einzeln durch. Wähl die Karten direkt auf dem Board aus, mit Cmd- oder Strg-Klick einzeln, mit Shift-Klick einen Bereich, und verschieb oder lösch die ganze Auswahl auf einmal.
Die Faustregel: Wenn du die Antwort schon kennst, bevor du die Aufgabe öffnest, gehört sie in einen Stapel. Das Durchgehen ist für die Berichte, die Urteilsvermögen brauchen, und das Bündeln sorgt dafür, dass sie deine volle Aufmerksamkeit bekommen und nicht den Rest davon.
Duplikate zuerst zu gruppieren ist die Gewohnheit mit der größten Hebelwirkung in der Triage. Sie macht regelmäßig aus vierzig Einträgen im Eingang sechs echte Aufgaben, und alles danach wird billiger. Der Leitfaden zum Triage-Workflow im Hilfe-Center beschreibt die komplette tägliche Routine.
Mit einem Link übergeben, nicht mit einer Beschreibung
Triage endet damit, dass Arbeit an jemand anderen geht, und genau hier versickert die gesparte Zeit meist wieder. Einen Bug in Slack neu abzutippen, mit einer halben Zusammenfassung, einer groben Reproduktion und einem Screenshot, dauert länger als die Triage selbst und enthält weniger als der Bericht, den du gerade angesehen hast.
Kopier stattdessen den Link zur Aufgabe. Ein Link trägt die Beschreibung, jeden angehängten Bericht, die Console-Ausgabe, die Netzwerkaktivität, die Umgebung und die bisherige Diskussion. Wer ihn bekommt, sieht, was du gesehen hast, und nicht deine Erinnerung daran.
Wenn dein Team mit einem KI-Assistenten debuggt, ist dieselbe öffentliche ID die ganze Übergabe: Richte Claude Code über MCP auf die Aufgabe, und er liest Berichte, Logs und Traces direkt, statt davon erzählt zu bekommen.
Wie oft ein Durchgang sinnvoll ist
Zehn bis fünfzehn Minuten, einmal am Tag. In einer Release-Woche zwei- oder dreimal täglich.
Täglich ist wichtiger als lang. Triage-Schulden wachsen auf eine bestimmte Art: Je älter ein Bericht ist, desto schwerer lässt er sich reproduzieren, desto wahrscheinlicher ist die Person, die ihn gemeldet hat, längst weg, und desto wahrscheinlicher ist er ein Duplikat von etwas, das seitdem hereinkam. Ein Backlog, den du eine Woche liegen lässt, ist eine Woche später nicht derselbe Backlog. Er ist schlechter.
Fehlermuster, die einen Namen verdienen
Triage in der Reihenfolge des Eingangs. Die Reihenfolge des Eintreffens ist nicht die Reihenfolge der Wichtigkeit. Erst filtern, dann eine Warteschlange abarbeiten.
Alles lesen, bevor irgendetwas entschieden wird. Ein Durchgang, in dem nichts die Spalte wechselt, hat nicht stattgefunden.
Eine Spalte „Infos fehlen“. Sie wird zu dem Ort, an dem Aufgaben vergessen werden. Frag jetzt bei der Person nach, die den Bug gemeldet hat, oder schließ die Aufgabe.
Alles ist kritisch. Ein Backlog, in dem jede Aufgabe dringend ist, enthält genauso viel Information wie einer, in dem keine es ist.
Nie etwas schließen. Der häufigste Fehler in der Triage ist nicht falsche Priorisierung, sondern eine Zahl offener Aufgaben, die nur wächst, bis das Board die Realität nicht mehr beschreibt.
Probier es auf deinem eigenen Board
Wenn du BugDump schon nutzt, steht der Ablauf ab sofort bereit: Board filtern, erste Karte anklicken und mit J und K durch die Spalte gehen. Die übrigen Steuerelemente des Panels erklärt Mit Aufgaben und dem Board arbeiten.
Von 40 Berichten zu 6 Bugs: wie Triage funktionieren sollte – warum Berichte und Aufgaben getrennt gehören und doppelte Berichte beim Debuggen helfen.
Bug-Tracking-Metriken, die wirklich zählen – vier Zahlen, an denen du siehst, ob dein Team mit den Bugs hinterherkommt, und ein Wochen-Review in fünf Minuten.
So schreibst du einen guten Fehlerbericht (mit Checkliste) – welche Details den meisten Fehlerberichten fehlen und wie eine Checkliste sie einsammelt.