Das ideale Bugticket und seine Rolle in der Softwarequalitätssicherung

Heute beschäftigen wir uns mit dem idealen Bug-Ticket.

Das ideale Bugticket existiert nicht… denn der Wunsch aller Software-Entwickler – und das schließt die Qualitätssicherung mit ein – ist eine fehlerfreie Software.
Da dieser Wunsch wohl ein Traum bleiben wird, wollen wir uns mit der Frage befassen, welche Angaben ein solches Bugticket umfassen sollte.

 Angaben im idealen Bugticket

  • Überschrift – die Überschrift sollte präzise auf den ersten Blick die Auswirkung und Ursache eines Fehlers darstellen.
    Ein schlechtes Beispiel wäre wohl „Datenverlust in Applikation“
    Gut hingegen „Datei wird nicht überschrieben, wenn Button Speichern gedrückt wird“
  • Die Beschreibung – sie sollte detailliert erklären, was der konkrete Fehler ist. Außerdem muss sie eine Beschreibung enthalten, wie der Fehler reproduziert werden kann. Welche konkreten Schritte sind zu unternehmen.
    Dies ist zwingend erforderlich für den Entwickler, der den Fehler finden soll, und für den Tester, der nachher die Behebung des Fehlers feststellen muss.
    Ein Fehler, der nicht reproduzierbar ist, kann nicht behoben werden!
    Vergessen Sie nicht zu erwähnen, in welcher Version der Fehler auftrat. Eine Behebung findet manchmal Wochen oder Monate später statt, und der Fehler ist auf dieser Version dann schon „zufällig“ durch jemand anderen behoben worden.
  • Arbeiten Sie im Projekt mit einer Komponenten-Einteilung, oder sonstigen Zuweisung?
    Dann tun Sie Ihren Kollegen einen Gefallen, und wählen Sie gleich die richtige Komponente aus. Eine falsche Komponente sorgt im Zweifelsfall dafür, dass ein Ticket nicht bearbeitet werden kann.
  • Haben Sie eine bestimmte Konfiguration Ihres Programms, die erforderlich ist, um den Fehler zu reproduzieren?
    Nutzen Sie die Möglichkeit, Dokumente an das Bugticket anzuhängen.
    Dasselbe gilt für Logdateien, auch diese sind häufig hilfreich bei der Fehlerfindung
  • Einteilung eines Fehlers in Bezug auf die Schwere:
    In manchen Ticketing-Systemen ist nur es möglich, eine Wahl zwischen „Hoch“, „Mittel“, „niedrig“ zu treffen.
    Andere Systeme hingegen erlaube eine Einteilung in 2 Dimensionen: Dringlichkeit und Schwere des Fehlers. Diese Einteilung werden wir zu einem späteren Zeitpunkt detailliert behandeln.An dieser Stelle nur soviel: Die Dringlichkeit gibt an, wie schnell ein Fehler behoben werden muss („spät“, „sofort – die Testabteilung kann sonst nicht weiter arbeiten“). Die Schwere des Fehlers hingegen gibt an, mit welchen Folgen ein Fehler verbunden ist (kritischer Fehler – „Datenverlust“, kosmetischer Fehler – „Tippfehler“).Auch ein Tippfehler kann ein release verhindern, zum Beispiel, wenn die Email-Adresse des Unternehmens falsch eingetragen ist.

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

Umfang der Testaktivitäten

Testen ist aufwändig, und scheint zunächst keinen zusätzlichen Nutzen zu bergen. Die Idee ist nicht, dass man zusätzlichen Ertrag erzeugt, sondern Schaden im Vorfeld vermeiden kann.
Doch wie viel Aufwand soll ins Testing investiert werden?
Diese Frage kann nur das Produktteam in seiner Gänze beantworten.
Eine pauschale Antwort lässt sich auf diese Frage nicht geben.
Der Umfang der Software-Tests hängt davon ab, wie viel Zeit investiert werden kann – auf der einen Seite – und auf der anderen Seite, wie hoch der Schaden ist, wenn sich im ungetesteten Teil Fehler finden. Einer Raumsonde, die Sie auf die Reise zum Mars schicken, können Sie schlechter ein Software-Update einspielen als dem Web-Shop, den Sie auf der eigenen Homepage verwenden…
Als Software-Tester / Test-Manager habe ich mir über die Jahre angewöhnt zu behaupten, dass nur Code, der durch dedizierte Test-Team-Mitglieder überprüft (und abgenickt!) wurde, als funktionierend anzusehen.
Im Umkehrschluss heißt das: Alles, was ein Tester sich nicht angeschaut hat, ist als defekt anzusehen!
Das mag im ersten Moment hart und zynisch klingen, rettet aber vor unangenehmen Überraschungen…
Insofern empfehle ich, dass der komplette Produktumfang zumindest einmal stichpunktartig geprüft werden sollte.
Je näher der Programmteil mit solchen Teilen verknüpft ist, die einer geplanten Änderung unterlagen, desto größer ist die Chance, dass sich hier Fehler ergeben. Und, je mehr Fehler sich in einem Bereich finden, desto „lohnender“ ist es, sich diesen Bereich näher anzuschauen.
Auf der einen Seite haben wir also nun die Bereiche identifiziert, die besonders wichtig zu testen sind. Wenn Sie, auf der anderen Seite, ein Produkt erweitern, gibt es sicherlich gibt es auch in Ihrer Software Programmteile, die schon seit Jahren unverändert gut laufen. Bei diesen Programmteilen kann man sich erlauben, die Tests in geringerer Intensität durchzuführen.
In meiner Rolle als Test-Managers besteht die Aufgabe auch darin, in der zur Verfügung stehenden Zeit die optimale Testabdeckung anzustreben. Daher werde ich mich hier immer wieder, gerade zu Anfang des Projekts, intensiv mit dem Entwicklungs-Leiter und dem Projekt-Manager beraten, wieviel Zeit für welche Test-Aktivitäten investiert werden kann, und wo diese Zeit am sinnvollsten investiert ist.
Auch das ist ein Prozess, der erlernt werden will.
Und wenn das Team sich zuviel vornimmt?
Dem Produkt-Verantwortlichen obliegt es dann ggf., einen Liefertermin anzupassen, den Projektumfang zu reduzieren oder mit einem (potentiell) fehlerbehafteten Produkt zu leben.
Um es nicht so weit kommen zu lassen, sollte die Entwicklung die Software-Qualitätssicherung, das Testing als Teil der notwendigen Arbeit akzeptieren.