agil oder klassisch?

Silvio Moser ist Co-Gründer und CTO der SwissQ Consulting AG. Er ist seit 1997 in der Software-Qualitätssicherung tätig und nebst seinen Aufgaben in der Geschäftsleitung auch als Management-Berater und als Referent unterwegs. Stephan Wiesner ist Head of Testing bei SwissQ und vielfach in agilen Projekten als Testmanager unterwegs. Er veröffentlicht regelmässig Fachbücher bzw. Fachartikel und tritt als Sprecher auf Fachkonferenzen wie dem Swiss Testing Day auf. Klassisches Testmanagement legt den Fokus auf Führung und Steuerung. Der Prozess ist zudem sehr dokumentenlastig: Testkonzepte und Testpläne müssen erstellt, Testspezifikationen in Auftrag gegeben, Testprotokolle ausgewertet und Testberichte angefertigt werden. Der ganze Vorgang hört sich wie das völlige Gegenteil von agil an. Muss dieser Ablauf in agilen Projekten also komplett über Bord geworfen werden? Ein Blick auf beide Welten – aus der Sicht des jeweiligen Testmanagers – hilft bei der Antwort. Ähnlichkeiten mit bekannten Personen sind rein zufällig.

Der erste fiktive Testmanager – nennen wir ihn Silvio – ist mit der klassischen Software-Entwicklung gross geworden und hat die Zertifizierung zum Testmanager mit dem ISTQB Advanced Level schon vor Jahren erlangt. Er sieht seine Aufgabe vor allem darin, die Testaktivi­täten zu planen und zu steuern.
Sobald Silvio in ein Projekt berufen wird, durchforstet er das Projektlaufwerk und studiert Projektplan, Architekturskizzen und Anforderungsdokumente. Darauf basierend entwirft er das Testkonzept. Da das Release noch nicht fertig geschnürt ist, bleibt insbesondere die Testplanung noch etwas vage. Das Projekt wird im Testmanagement-Tool eingerichtet, der Testdesigner beginnt, die Testfälle zu schreiben. Dies ist eine arbeitsintensive Phase, da es für etliche Anforderungen noch unklar ist, wie sie genau funktionieren sollen. Man behilft sich, indem man Abläufe modelliert und Entscheidungstabellen erstellt. Auf der nächsten Seite: Der agile Ansatz Nach langer Vorbereitungsphase und ein paar Wochen verspätet wird die Software in die Testumgebung ausgeliefert. Silvio legt nun sein Augenmerk auf die Koordination der Tester, die Auswertung der durchgeführten Tests und auf die gemeldeten Fehler. Während die Tester anfangs nur wenige Fehler finden, da die Software noch recht instabil ist, sind es später fast zu viele. Im Projektteam wird ständig darüber diskutiert, ob nun die Software, der Testfall oder die Anforderung falsch ist. Silvio macht eine Auswertung nach der anderen und rennt von Sitzung zu Sitzung. Mit der Zeit flacht die Fehlerfindungskurve jedoch wieder ab und ein Grossteil der Fehler kann behoben werden. Der Go-Live wird mit einem Apéro gefeiert, an den man sich noch lange erinnern wird. Das beschriebene Testmanagement nach dem Wasserfallprinzip zeichnet sich dadurch aus, dass die Aktivitäten mehr oder weniger sequenziell ablaufen. Das heisst, man hat genügend Zeit für die Vorbereitung – vorausgesetzt, der Testmanager wird früh genug ins Projekt eingebunden. Gegen Projektende wird es jedoch meist sehr hektisch, da Design und Entwicklung oft länger dauern als geplant und der Einführungstermin nicht verschoben werden kann. Dadurch verkürzt sich die Testphase, aber die Arbeit wird nicht weniger.

Unser zweiter Testmanager – nennen wir ihn Stephan – hat Informatik studiert und schreibt gerne auch noch selbst Code. Er ist seit Langem zertifizierter Scrum-Master, sieht sich als vollwertiges Mitglied des Entwicklerteams und kann sich mit diesem problemlos über technische Details unterhalten. Die kurzen Iterationen in agilen Projekten mit einem «potentially shippable Release» alle 3 bis 4 Wochen stellen Stephan vor andere Herausforderungen als Silvio. Statt monatelanger Vorbereitungsphasen werden viele notwendige Aktivitäten parallel zur Entwicklung durchgeführt. Zwar erstellt auch der agile Testmanager anfangs ein Testkonzept, die Anforderungen erhält er aber gleichzeitig mit den Entwicklern – und wenige Tage später meist schon eine erste Version der Software zum Testen. Ein typischer Tag beginnt für Stephan mit dem morgendlichen Team-Meeting (Stand up). Kurz wird besprochen, wer an diesem Tag was macht, wo die aktuellen Probleme liegen und welche Bereiche für einen Test parat sind. Die Testfälle werden parallel zur Entwicklung erstellt. Stephan ist dafür verantwortlich, dabei auftretende Fragen direkt mit dem Kunden­vertreter zu klären und zu dokumentieren. Der agile Testmanager muss als Teil des Teams der Vermittler zwischen Entwicklung und Kundenvertreter sein. Er trägt beide Hüte und vertritt beide Seiten. Der Vorteil liegt auf der Hand: Offene Fragen und kleine Änderungen können zu dem Zeitpunkt erledigt werden, an dem der Entwickler noch das jeweilige Modul programmiert. Es gibt keine langen Freigabe-Meetings und keine sperrigen Prozesse. Im Vordergrund steht die Zielorientierung – und zwar (hoffentlich) ohne im Chaos zu versinken. Auf der nächsten Seite: Fazit Erst wenn die Software getestet ist und keine kritischen Fehler mehr offen sind, gilt das Arbeitspaket als fertig (Definition of Done) und wird dem Kunden für die Durchführung der Abnahmetests und zur finalen Freigabe in die Hand gegeben. Dabei handelt es sich typischerweise um kleine Tests mit wenigen Kundenvertretern, die sich an einem Tag erledigen lassen,  dies jedoch mehrfach im Projekt. Stephan hat hier wie Silvio die Aufgabe, den Test optimal vorzubereiten und die beteiligten Kunden­vertreter zu begleiten. Dafür werden die fertiggestellten Funktionalitäten mittels möglichst nah am Alltagsgeschehen der Anwender angelehnter Szenarien getestet. Das Ergebnis dieser Tests ist weniger eine formale, vertragsrelevante Liste mit Fehlern als vielmehr eine Liste mit potenziellen Optimierungen, sogenannten Issues. Der Kunde entscheidet, ob der Preis für deren Umsetzung den potenziellen Nutzen wert ist. Die Herausforderung für den Testmanager liegt hier weniger im technischen Bereich als vielmehr darin, mit viel Fingerspitzengefühl die (Kunden-)Erwartungen zu steuern und den Fortschritt des Projekts zu sichern.

Wir haben nun beide Welten gesehen. Ein guter Testmanager in Wasserfallprojekten ist immer auch ein guter Organisator. Er muss systematisch arbeiten und sich in starren Strukturen wohlfühlen. Der agile Testmanager hingegen muss flexibel sein. Er darf sich nicht als reiner Koordinator sehen und ist für alle Testaufgaben zuständig: managen, vorbereiten, durchführen und berichten. Geplant wird trotzdem, aber mittels Backlog statt Projektplan. Umso wichtiger ist, dass die Testaspekte laufend eingebracht und korrekt eingeschätzt werden. Auch wenn meist ohne detaillierte Testfälle getestet wird, muss eine ausreichende Testabdeckung sichergestellt werden und es sind entsprechende Regressionstestfälle aufzubauen. Nicht zuletzt muss auch in agilen Projekten transparent über den Testfortschritt berichtet werden können. Es liegt auf der Hand, dass in der Hektik des Alltags die eher systematischen Aspekte des Testmanagements Gefahr laufen, über Bord geworfen zu werden. Genau hier liegt die Kunst des agilen Testmanagements, die althergebrachten Techniken schlank und rank einzusetzen und so in die agile Welt zu überführen.