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

Schritte der Software-Entwicklung

Für diejenigen Leser, die sich mit der Software-Entwicklung noch nie beschäftigt haben, möchte ich nun einen kurzen Einblick in die Schritte der Software-Entwicklung liefern.
Dieser Einblick ist deswegen relevant, damit man sich vor Augen führen kann, welche Werkzeuge (die wir als nächstes beleuchten) erforderlich sind, um eine Software zu entwickeln.

Die Schritte in der Software-Entwicklung:

  1. Schritt – Anforderung – Aufgabenstellung
    Die Software-Entwicklung erhält eine Anforderung in einer allgemeinverständlichen Sprache („Wir brauchen eine Software, die … erledigt“)
  2. Die Software-Entwicklung nutzt eine sogenannte Hochsprache, z.B. C, C++, C# oder Java, um die Anforderung in Quellcode umzusetzen.
    Der Quellcode ist noch nicht direkt auf der sogenannten „Zielplattform“ ausführbar.
  3. Mittels eines Compilers, der Teil eines Build-Systems sein kann, wird der Quellcode in „Maschinencode“ übersetzt.
    Der Maschinencode ist zwar vom Prozessor ausführbar, kann aber nicht mehr ohne großen Aufwand, von Menschen verstanden werden.
    Zudem sprechen verschiedene Prozessoren unterschiedliche Sprachen.
    Das ist – grob gesagt – einer der Gründe, warum Sie nicht einfach Windows 10 auf einem iPhone installieren können

Der so hergestellte Quellcode kann nun mit einem Installationsprogramm gepackt werden und dann über die eigene Homepage oder einen App-Store für Kunden bereitgestellt werden.