Agile / Testmanagement

Alles Agil – hat der Teststatusbericht ausgedient?

Agile Vorgehensmodelle haben nicht nur die Entwicklung sondern auch das Vorgehen in der Qualitätssicherung revolutioniert. War früher der Teststatusbericht ein wesentlicher Indikator für den Projektfortschritt, regieren heute Taskboards, Teamverantwortung und das Commitment „Fertig heißt Qualitätsgesichert“. Braucht da noch jemand einen Testbericht?

Tatsächlich mag der Teststatusbericht in einem kleinen, vollständig agilen Projekt unnötig sein: der Test wird einfach auf dem Taskboard berücksichtigt.  Doch sobald das Projekt größer wird, sieht es oft anders aus.

 

https://pixabay.com/de/users/geralt-9301/

Quelle: https://pixabay.com/de/users/geralt-9301/

 

Nicht nur meiner Erfahrung nach gibt es verschiedene Stufen von „agil“ (siehe auch Reise zur bimodalen IT). Erfolgt die Entwicklung bereits nach agilen Methoden, so bedeutet dies noch nicht, dass auch der Test, insbesondere der Akzeptanz- oder Abnahmetest des Kunden im agilen Prozess integriert ist. Ist der Test  agil, kann es im Management noch Bedarf an – nennen wir es mal – „klassischen“ Statusinformationen geben. Statt den Testbericht sofort zu verbannen, sollte man herausfinden, wer worüber informiert sein muss und ob eine explizite Information erforderlich ist.

 

Argumente für den Testbericht

Nicht auf den Testbericht verzichten möchte ich, u.a. wenn

  • Fortschritt und Probleme zwar im Werkzeug ersichtlich sind, das Management oder andere Beteiligte aber nicht darauf zugreifen können (oder wollen)
  • Stories „fertig“ sind, sich aber trotzdem offene Fehler ansammeln
  • Aus dem Werkzeug keine Gesamtsicht auf das Projekt möglich ist
  • Nachweispflichten (z.B. zum Risikomanagement) eine textuelle Dokumentation von Situation und Maßnahmen erfordern

Trotzdem bedeutet dies nicht, dass der klassische Testbericht unverändert in die agile Welt übernommen werden sollte. Nur Informationen, die auch im agilen Vorgehen relevant sind, sollten verwendet werden.

 

Was soll enthalten sein?

Ein guter agiler Testbericht enthält Informationen über:

  • Den Teststatus der aktuell fertiggestellten Stories oder Epics
  • Den Teststatus der (automatisierten) Regressionstests
  • Anzahl und Trend der offenen Defects
  • Einen Textteil mit
    • Wesentlichen Vorkommnissen (als Interpretationshilfe für beigefügte Statusgrafiken)
    • Aktuellen Risiken und Problemen, die Managementaufmerksamkeit erfordern

Zusätzlich sinnvoll sind:

  • Ein kurzer Ausblick auf geplante Aktivitäten
  • weitere Indikatoren und Trends zur Bewertung der Prozessqualität, z.B.
    • Anteil von Fehlern, die in späteren Teststufen oder im Produktivbetrieb gefunden wurden
    • Anzahl automatisierter Regressionstests bzw. abgedeckter Funktionen/Stories etc. (sollte ansteigen)
    • Anteil fehlgeschlagener bzw. nicht lauffähiger Regressionstests (sollte gegen 0 gehen)

 

Behebungsdauer von Fehlern

 

Und das Format?

Viele dieser Informationen werden sich in Werkzeugen oder auf Teamdashboards finden. Eine kompakte Zusammenstellung für alle Interessierten ist dennoch nützlich – vor allem auch bei verteilten Teams. Wie und wo diese präsentiert wird, ist abhängig vom Adressatenkreis und den verfügbaren Werkzeugen. Meine persönlichen Favoriten sind webbasierte Testberichte mit direktem Zugriff auf Auswertungen (z.B. Jira/Confluence) sowie Excel aufgrund der flexiblen Auswertemöglichkeiten. Kommentarmöglichkeit vorausgesetzt, können auch eigens eingerichtete Qualitydashboards den Zweck erfüllen: Testbericht ganz agil.

 

Passende Artikel

3 Kommentare

  1. die Praxis beweist, dass das klassische „Lagerdenken“ (traditionell – agile) nicht geeignet ist, professionelle Qualitätssicherung sicherzustellen.
    Daher sei dieser Blog von A.Kling jedem Tester / Testmanager / AgileTeamMemberMitTestbackground ins Stammbuch geschrieben.

    • Franz Kindler sagt:

      Helmut, soll das heißen, dass professionelle Qualitätssicherung oft nicht möglich ist?

  2. Hallo Franz, deine Frage lässt sich nicht einfach mit JA oder NEIN beantworten. Warum? Qualitätssicherung brauchte sehr lange bis es in den Software Lifecycle bzw. in den Entwicklungsprozess etabliert wurde (Initiativen wie ISTQB® haben hier gut dazu beigetragen und ein einheitliches Verständnis und Wording geschaffen). Und auch wenn das Selbstverständnis „gute Qualität zu liefern“ zunahm, wurde QS dennoch oft gekürzt oder gar geopfert bei Zeitverzug o.ä.. Meiner Erfahrung nach war das Test Reporting seitens des Projektmanagements jedoch meist sehr willkommen, da es oft das einzige „griffige“ war, wonach sich die Projektleiter orientieren konnten. Und jetzt gibt es Agile – heute sozusagen „en vogue“, wenn man auf den IT-Markt schaut und auf Fachkonferenzen zuhört. Und auch wenn das Testen im agilen Manifest nicht explizit genannt ist, finden wir „Tester“ uns dennoch in vielen Punkten der agilen Praktiken wider. Leider zeigt sich, dass die Praktiken aber vielfach nur „halbherzig“ implementiert werden und das Management doch noch oft auf altbewährte „Testreports“ besteht – und hier gilt es dann ein vernünftiges, an die jeweilige Situation angepasstes Reporting zu finden. Ein, wenn nicht DER Successfaktor bei Projekten ist, dass das Management voll dahintersteht und auf das/die Team/s vertrauen. Werden die agilen Praktiken auch wirklich nennenswert umgesetzt, ist ein laufender Qualitätsfortschritt – auch fürs Management – klar sichtbar. Professionelle Qualitätssicherung ist meiner Meinung nach immer möglich, egal ob mit traditionellem oder agilem Vorgehen. Es kommt nur darauf an, worauf Stakeholder ausgerichtet sind: auf Qualität oder die Einhaltung von „schon immer gelebten“-Prozesse.