Bug-Triage – was soll das?

In diesem Artikel widmen wir uns der „Bug-Triage“.
Es handelt sich dabei um einen Teil-Prozess, der Software-Entwicklung, der in den späteren Projektphasen zum Tragen kommt.
Eine Triage wird abgehalten, um die anfallenden Bug-Tickets nach Schwere einzuteilen bzw. die bisher getroffenen Einschätzungen zu revidieren.
Der Begriff ist entliehen aus der Beurteilung von Verletzten in Großschadenslagen. Das medizinische Personal muss hier sinnvoll eingesetzt werden, da es mehr Patienten gibt als man gleichzeitig behandeln kann. Daher wurde dieses Verfahren entwickelt, um schnell festzustellen, welche Patienten dringend Hilfe bedürfen – wegen lebensgefährlicher Verletzung, und welche Patienten nur leicht verletzt sind.
Und in der Software-Entwicklung?
Hier ist eine Bug-Triage anzuberaumen, wenn die Zeit bis zum Liefertermin nicht mehr ausreicht, um alle offenen Bugtickets bearbeiten zu können. Dies ist leider häufig der Fall. Es wird immer wieder Fehler geben, die man nicht rechtzeitig beheben kann.
Zum Glück haben wir in der Software-Entwicklung manchmal die Alternative, ein Release zu verschieben, aber das ist weder die Entscheidung der Qualitätssicherung noch die Entscheidung der Entwickler.
In der Bug-Triage sitzen deshalb typischerweise mindestens folgende Rollen vereint an einem Tisch:
  • ein Vertreter der Software-Qualitätssicherung – er kann Auskunft über die einzelnen Bugtickets geben, und einschätzen, wie schwerwiegend ein Fehler ist
  • ein Vertreter der Entwicklung – er kann Auskunft darüber geben, wie aufwändig ein Fehler zu beheben ist, und ob ggf. Seiteneffekte zu beachten sind, die der Qualitätssicherung noch nicht bekannt sind
  • eine Vertreter des Projekt-Managements – er kann abschätzen, ob man einen Fehler im Produkt eher akzeptieren kann als einen verschobenen Liefertermin – oder umgekehrt.
Manchmal wird auch explizit noch der Product Owner, der die Produktverantwortung im Haus trägt, diesen Treffen beiwohnen.
Ziel dieser Treffen ist es, sich möglichst schnell auf einen Weg zu einigen, wie mit den Patienten – also den einzelnen Fehlern – umgegangen werden soll. Welcher Fehler ist „lebensgefährlich“ und wird daher sofort behandelt? Welche Fehler ist „hinnehmbar“, und die Behandlung kann auf später vertagt werden?
Um das Treffen effizient zu gestalten, sollte allen Parteien genügend Gelegenheit gegeben werden, die Bugreports vorab zu lesen, und eine Klassifikation im Sinne eines Schweregrads und Aufwands vornehmen zu können. So können einzelne Analysen im Treffen vermieden werden.
Üblicherweise wird man die Bewertung eines Bugtickets in Bezug auf Schwere und Dringlichkeit überarbeiten. Zusätzlich wird man einen Schwellwert setzen, bis zu dem Fehler noch bearbeitet werden – bzw. welche Fehler im Release noch enthalten sein werden.
Wann ist eine solche Bug-Triage sinnvoll?
Die Triage wird in dem Moment erforderlich, wenn man merkt, dass die Projektzeit „knapp“ wird, wenn also der Liefertermin bei Fehlerfreiheit nicht garantiert werden kann.
Was sind die Risiken, wenn man diese Triage nicht durchführt?
Die Partei, die im Unternehmen den stärksten Einfluss hat, wird siegen.
  • die Software-Qualitätssicherung könnte das optimale Produkt fordern, ohne Rücksicht auf den Liefertermin
  • die Entwicklung arbeitet möglicherweise nicht an den wichtigen Bugtickets
  • das Projekt-Management muss ein Produkt liefern, welches mehr Fehler besitzt als erforderlich

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.