Für die ATB-Insider Interviewreihe "Auf einen Kaffee mit..." traf ihn zum Frage&Antwort-Spiel und stellte dabei die eine oder andere ketzerische Frage zum Thema „Agile Testing“.
Q: Herr Baumgartner, gleich eine ketzerische Frage zum Einstieg. Stirbt der traditionelle Tester, also der nicht agile Tester, aus?
MB: Für die Beantwortung dieser Frage ist es von Bedeutung, was man unter einem traditionellen Tester versteht: Wenn „traditionell“ bedeutet, dass der Tester im Anschluss an lange Analyse- und Entwicklungsphasen wochen- oder gar monatelange Tests durchführt und es vielleicht – auf Grund der Größe des Vorhabens – gar nicht auffällt, wenn der individuelle Fortschritt einmal nicht so gegeben ist, dann wird der traditionelle Tester wohl aussterben.
Besagt „traditionell“ jedoch die Beherrschung von bewährten und effizienten Testmethodiken, dann ist der agile Tester eine spezifische Ausprägung des traditionellen, professionellen Testers unter sehr herausfordernden Rahmenbedingungen.
Q: Agiles Testen hört sich für manche an nach „Chaos“ und „Jeder macht was er will“. Was sagen sie dazu? Wie definieren sie „Agile Testing“?
MB: Agile Testing ist ganz das Gegenteil von „Jeder macht was er will“. Stärker als in traditionellen Vorgehensweisen ist er gleichberechtigtes Mitglied des Entwicklungsteams und dem konstruktiven Entwicklungsprozess „committed“. Es geht also weniger um das „destruktive“, nachgelagerte Fehlerfinden, wozu jedes Mittel legitim ist, sondern um die aktive Mitgestaltung in der Erarbeitung und regelmäßiger Bereitstellung von Business Value in Form eines funktionstüchtigen Release der geplanten Applikation. Um dieses zu erreichen, muss sich auch der Tester dem übergeordneten Ziel des agilen Teams unterordnen und ein Testverfahren und Testmethodiken wählen, die die bestmögliche Qualität und somit die Absicherung des Geschäftsnutzen sicherstellen.
Q: Was zeichnet einen agilen Tester aus.
MB: Den agilen Tester zeichnen insbesondere drei Fähigkeiten aus.
Erstens: die Fähigkeit, den für die konkrete Aufgabenstellung richtigen Testansatz und die richtigen Testmethoden und –techniken zu wählen. Dies bedingt einerseits die Kenntnis dieser Methoden und andererseits die Erfahrung, Kreativität und Flexibilität in deren Anwendung.
Zweitens: Konsequenz und Ausdauer, um unter dem Druck des oft engen zeitlichen Korsetts in Agilen Projekten (kurze Iterationen, „working software“ am Ende jedes Sprints) nicht auf erlerntes und bewährtes Wissen zu vergessen und in ein Chaos-Vorgehen zu verfallen und
Drittens: Kommunikationsfähigkeit, da nur über eine sehr gut funktionierende direkte Kommunikation mit allen Teammitgliedern, sei es Entwickler, Product Owner, Endanwender oder sonstige Stakeholder, die Synergien eines Agilen Teams realisiert werden können.
Insider: In SCRUM gibt es die Rolle des Testers nicht, da gibt es keine Spezialisten. Wie würden sie das Thema Test dort verankern?
MB: Dies ist im Wesentlichen dem Umstand zu verdanken, dass die „Erfinder“ von SCRUM und die einschlägigen Autoren Entwickler und keine Tester waren. Aber es sei ihnen verziehen, denn würde ich als Tester ein Vorgehensmodell entwickeln, dann würde dies darauf beruhen, dass der Endanwender Business-Modelle formuliert, aus denen der Code direkt generiert wird und die Ergebnisse durch Tester validiert werden. Der klassische Entwickler wäre nur mehr in Ausnahmefällen von Nöten.
Aber Scherz beiseite: SCRUM geht hier an den Notwendigkeiten und der Realität vorbei. Ein gutes SCRUM-Team besteht aus Requirements-Engineers, eine Rolle, die manchmal durch den Product Owner eingenommen werden kann; es hat einen exzellenten Architekten im Team, der unter Umständen auch mit entwickelt und dafür sorgt dass die Architektur trotz vieler kommenden Änderungen stabil und flexibel zugleich ist; es besteht aus hervorragenden Entwicklern, die im kurzen Sprints sowohl neue Features entwickeln, Fehler beseitigen und ein laufendes Refactoring durchführen; und es umfasst ein Team von ausgezeichneten Testern, denen es in optimaler Weise gelingt eine hohe, nachvollziehbare Testabdeckung zu erreichen, die neuen Features zu testen und gleichzeitig – unter Einsatz von funktionaler Testautomatisierung – die notwendigen und mit jedem Sprint umfangreicher werdenden Regressionstests durchzuführen. Wenn man sich dies vor Augen führt wird deutlich, dass die SCRUM-Interpretation „Jeder kann und macht alles“ eine Illusion ist.
Q: Das ISTQB geht nicht näher auf Agile Testing ein. Wie passt die ISTQB-Zertifizierung als Ausbildung dann mit Agile Testing zusammen?
MB: Wie bereits erwähnt steht Agile Testing nicht im Widerspruch zu den ISTQB-Zertifizierungen, in denen insbesondere viele Grundlagen, Techniken und Methoden des Software Tests vermittelt werden, die ganz besonders in Agilen Projekten zum Einsatz gelangen. Mittlerweile wurde auch der Certified Agile Tester® CAT ins Leben gerufen (www.agile-tester.org). ANECON bietet seit Anfang des Jahres ein Seminar „Agile Testing“ an und ist ebenfalls CAT – Training Provider und gleichzeitig ISTQB-akkreditiertes Unternehmen – und wir betrachten diese Ansätze in einer synergetischen Ergänzung.
Q: Exploratives Testen = Session Based Testing = Agil. Stimmt die Gleichung?
MB: Die Gleichung stimmt insofern nicht, als dass weder der Explorative noch der Session Based Test eine agile Erfindung sind und man einen schweren Fehler begeht, wenn man „Agil“ auf diese Testtechniken reduziert. Der Einsatz dieser Techniken muss auf den jeweiligen Einsatzzweck und auf die angestrebten Qualitätsziele abgestimmt sein. Wichtiger in Agilen Projekten erscheinen mir jedoch die Optimierungsmöglichkeiten eines Risikobasierten Tests bzw. von Value Driven Testing sowie der konsequente Einsatz von Testautomatisierung.
Q: Brauche ich im Zeitalter von agile Testing noch einen Testmanager?
MB: Obwohl z.B. in SCRUM der Testmanager vorerst im wahrsten Sinn des Wortes keine Rolle spielt, prägt sich in fast allen Agilen und auch SCRUM-Projekten dies Rolle „natürlich“ aus – weil Erfahrung und Kenntnis in Testansätzen, -methoden und –techniken und in Aufwandsschätzungen immer benötigt werden. Der Testmanger ist dabei aber nicht mehr der Manager eines Teams von Testern sondern Manager des Tests in einem gleichberechtigten Team.
Q: Danke für das Gespräch.
Posts
