Kein Tester mehr in agilen Teams? Und wo ist der Testmanager hin? - Qualitätssicherung in der Softwareentwicklung und im Softwaretest

Wer die Einführungen zu agilem Arbeiten so durchliest, der kann auch der Meinung sein, dass Tester in agilen Teams nicht mehr notwendig sind. Erst vor kurzem nahm ich an einer Diskussion über Test Driven Development teil, bei der das Entwicklungsteam einen Tester oder Testmanager für vollkommen überflüssig hielt. Schließlich würden ja die Entwickler testen und Tests schreiben und das gesamte Team wäre für die Qualität verantwortlich.

Dem kann man zustimmen, schließlich können Entwickler auch testen und Projektmanager auch Rückschlüsse auf die Qualität ziehen.

Argumentiert wurde, dass von den Entwicklern ja bereits alles automatisiert getestet würde, ein Tester könnte somit nichts mehr beitragen. Werden trotzdem Fehler gefunden, müsste eben der automatisierte Test erweitert werden. Für die Qualität wurden Vorgaben gesetzt, diese werden mit statischen Tests geprüft und mit SonarQube ausgewertet, der Projektmanager hat somit alles im Blick. Durch eine automatische Buildpipeline könnte sogar wann immer möglich ein neues Release veröffentlicht werden. Somit wäre doch alles in Ordnung. In der Theorie zumindest.

In der Praxis war der Anteil an Tests entsprechend der Testpyramide aufgebaut. Die Testabdeckung war wie vorgegeben. Die Tests fanden aber nach Inbetriebnahme keine Fehler, Product Owner und Kunde jedoch schon.

Die Lösung war einfach, bei der Umsetzung wurde vernachlässigt die Fachlichkeit zu prüfen, beim Testen wurde aus zeitlichen Gründen vermieden auf Fehler zu prüfen.

Hier kommt der agile Tester ins Spiel, neben den Tests und Fehlerdokumentation, muss er vor allem eins können, er muss kommunizieren und zwar mit PO und Entwicklern auf Augenhöhe. Dazu muss er beide Welten in Gleichklang bringen, die Fachlichkeiten des Business Case und die Umsetzung in der Entwicklung verstehen. Diese Fähigkeit sollte er weiter nutzen, um die Automatisierung im Projekt zu unterstützen, egal ob im Test oder im Deployment.
Durch seine veränderte Sichtweise und geschulten Testmethoden, kann er über die Funktionalität hinaus weitere Qualitätsmerkmale prüfen, die bisher leidlich ungeprüft blieben.

Die Basis wäre somit solide gesetzt, was fehlt ist das Gesamtbild, für das bisher der Projektmanager verantwortlich war. Er hatte zwar die nötigen Tools für statische Codeanalyse und Continuous Integration konnte aber nur wenig damit anfangen. Hier kommt der Testmanager (oder Qualitätsmanager, Namen sind Schall und Rauch) ins Spiel. Er kann aus all den Zahlen sinnvolle KPIs identifizieren und in den Scrum Reviews den Teams vorlegen. Fehlentwicklungen kann somit zusammen mit dem Scrum Master und PO entgegen gewirkt werden. Die Qualität kann Projektübergreifend betrachtet und verglichen werden, ein oft vorhandenes Impediment in agilen Teams.

Des Weiteren kann er das vom Team erstellte Buildwerkzeug für eine Buildpipeline einsetzen und die automatischen Tests mitlaufen lassen und so automatisch bei Bedarf Fehlerbehebungen oder Change Management Prozesse einleiten. Wird ein Release benötigt, kann er gezielt darauf hinwirken, anstatt auf die Selbstheilungskräfte der Buildpipeline zu warten und zu hoffen.

Am Ende steht somit ein agiles Projektteam welches alle Bereiche der Code-Entwicklung, Merge und Build, Test und Qualität, Packaging und Release unter fachlicher Kontrolle hat und jedes Teammitglied sich voll einbringen kann, aber nicht alles können muss. Die Richtung ist somit klar, es geht in Richtung DevOps.