Testmanager neu positioniert

Früher war alles besser! Bekanntlich nicht. Früher war alles anders und das war auch gut so. Ansonsten gäbe es keine Weiterentwicklung, und das ist durchaus positiv gemeint. Hinsichtlich der Transformation von stringenten und separierten Wasserfall-Teams hin zu einer agilen Entwicklungsorganisation werden heute wohl die wenigsten bestreiten, dass dies ein positiver Schritt bezüglich der Effizienz und Effektivität von Teams und ihren Ergebnissen für den Kunden war und ist. Mit der Selbstorganisation von Scrum-Teams und der damit verbundenen Philosophie von Arbeitsteilung und Teamgeist werden auch verständlicherweise die klassischen Rollen überprüft. Das gilt nicht nur für den Projektmanager und den Requirements-Engineer, sondern auch für den Test-Manager und seinem klassischen Verantwortungsbereich. Betrachtet man die Struktur des Testings und die Rolle des klassischen Test-Managers sieht man, verglichen mit dem Entwicklungsteam, eine eigenständige Projektorganisation, die der Entwicklung meist in Form eines Service mit der Aufgabe die Qualität sicherzustellen angegliedert ist.

Jetzt könnte man meinen, dass sich mit der Etablierung von Scrum-Teams und der damit verbundenen Selbstorganisation die Rolle und damit verbundene Aufgabenspektrum des Test-Managers nicht mehr notwendig und damit obsolet sei. Das glaube ich nicht. Mit der Annahme, dass die Performance von Scrum-Teams anhand ihrer Sprint-Performance gemessen wird und am Ende eines Sprints immer ein produktreifes Deliverable steht, welches nicht unbedingt in Produktion gehen muss, ist ein Interessenskonflikt vorprogrammiert. Aus eigener Erfahrung sollte kein Entwickler seinen eigenen Code testen. Ausserdem wird das Thema Test Driven Development (TDD) in seiner ursprünglichen Idee nur unzureichend in die Teams integriert. Zu oft trifft man auf den Ansatz Dev first, Test later an. TDD erfordert ein hohes Mass an Disziplin und sehr starke Nerven, da der Entwickler bis zum Schluss die rote Ampel der Unit-Test-Suite sieht. Es erfordert ein stabiles Nervenkostüm, weil sich der Entwickler unter Umständen auch irgendwann fragen muss, ob der implementierte Test auch korrekt ist. Diskussionen wie zum Beispiel “Wer testet den Tester” kommen einem da in den Sinn. Zurück zur Rolle des Test-Managers in der neuen agilen Welt. Aus meiner Sicht wandelt sich die Manager-Rolle mit Budget-, Ressourcen- und Ergebnisverantwortung zu einer Coaching-Rolle, die innerhalb der Scrum-Teams durch seine methodische Expertise und das aktive Mittesten erheblich zur Qualitätssicherung und der damit verbundenen Kanalisierung von identifizierten Abweichungen zur Steigerung der Produktivität beitragen kann. Ich würde noch einen Schritt weiter gehen und die Rolle des aktiven Test-Coaches Team-übergreifend etablieren, um einheitliche Methoden und Quality Gates für die gesamte Scrum-Organisation zu definieren. Dies fängt bei der Formulierung von Checklisten und Reviews für die Annahme von Anforderungen für einen Sprint an und könnte final bei der Bereitstellung von automatisierten Regressionstests enden.

Der ehemalige Test-Manager wird in seiner Rolle zu einem festen und flexiblen Bestandteil der Scrum-Teams und fungiert als Coach, Mentor und Ideengeber für eine effiziente und effektive Qualitätssicherung. Er sollte auch einen fachlichen Heimathafen haben, der ihm die Möglichkeit gibt, seine methodischen Erfahrungen und neuen Ideen direkt in die Praxis umzusetzen. Dies unterstützt den heutigen Best Practice Ansatz und schafft Evidenzen, die zeigen, inwiefern sich Methoden und Erfahrungen für einen spezifischen Kontext umsetzen und in anderen Teams etablieren lassen.