Abb. 1: House of agile Testing
Im Rahmen einer agilen Transformation müssen wie bei jedem größeren Veränderungsprojekt zunächst einige Fragen beantwortet werden. Dies ist wichtig, um ein einheitliches Verständnis aller Beteiligten bezüglich der Transformation zu schaffen und somit auch die Grundlage für eine erfolgreiche Veränderung zu legen.
„House of agile Testing“
Erfahrungsgemäß sollten mindestens die folgenden Fragen beantwortet werden:
- Was wollen wir erreichen? (Welches geschäftspolitische Ziel wird mit der agilen Transformation verfolgt?)
- Welches agile Framework ist für unser Unternehmen am besten geeignet? Damit verbunden ist auch die Frage, welche Tools wir benötigen
- Was benötigen unsere Mitarbeiter, um die gesetzten Ziele zu erreichen und die Erwartungen zu erfüllen?
- Was benötigt unsere Organisation (als Ganzes betrachtet), um die gesetzten Ziele zu erreichen und die Erwartungen zu erfüllen und sie dauerhaft in die Organisationsstruktur und -kultur aufnehmen zu können?
Betrachtet man eine agile Transformation im Bereich des Tests, so bietet das House of agile Testing (siehe Abbildung 1) eine Orientierungshilfe, um alle wesentlichen Punkte im Bereich Test im Auge zu behalten. Für alle weiteren an der Softwareentwicklung beteiligten Fachdisziplinen finden zusätzliche Punkte Berücksichtigung.
Das Fundament des Hauses bilden die Test Basics, also die Grundlagen des Testens und der Qualitätssicherung. Dazu gehören sowohl ein fundamentales Verständnis des Testprozesses als auch die methodischen Grundlagen, wie beispielsweise das Wissen über Testfallentwurfsmethoden, Reviewtechniken und Defektmanagement (vgl. [IST-QB]).
Die Säulen des Hauses definieren die Arbeitsweise/Prozesse des Tests in einem agilen Umfeld. Abbildung 1 stellt die Inhalte der drei Säulen detaillierter dar.
Mit der detaillierten Beschreibung des Inhalts dieser drei Säulen allein ließe sich schon ein ganzes Buch füllen. Nachstehend wird daher nur kurz auf die wesentlichen Inhalte der Säulen eingegangen.
In der ersten Säule (Menschen und Rollen) gilt es, Fragen bezüglich der künftig notwendigen Rollen zu beantworten. Dies hängt einerseits von der gewählten agilen Softwareentwicklungs- beziehungsweise Skalierungsmethode ab, andererseits aber auch von der Frage, ob gegebenenfalls Spezialrollen für den Test benötigt werden. Direkt damit verbunden ist die Frage nach dem notwendigen technischen Wissen und Verständnis in den einzelnen Rollen. Insbesondere ist hier auch die Frage zu klären, inwiefern und in welchem Umfang technisches Wissen auf- und ausgebaut werden muss, um das notwendige Skillset, das mit den jeweiligen Rollen verbunden ist, im Unternehmen sicherzustellen.
Wenn die beiden vorangegangenen Fragen geklärt sind, gilt es schließlich, die organisatorischen Strukturen weiterzuentwickeln und letztlich die neuen beziehungsweise angepassten Rollen im Organigramm der Organisation abzubilden.
Die zweite Säule (Ansatz) beinhaltet die Frage nach dem Lieferansatz und der damit direkt verbundenen Herausforderung, wann was getestet werden muss. Insbesondere bei der Einführung von Agilität bei großen Entwicklungsprojekten, die Teil von komplexen IT-Systemlandschaften sind, wird oft ein hybrider Ansatz verfolgt. Die Software wird dann oftmals in Sprints entwickelt, aber erst nach mehreren Monaten im Rahmen eines normalen Release live gesetzt. Bei solchen Vorgehensweisen gilt es zu klären, welche Inhalte innerhalb der Sprints getestet werden müssen und können und was in einem nachgelagerten Test geprüft werden muss.
Die dritte Säule (Tools) beinhaltet schließlich die technischen und prozessualen Fragen der Toolauswahl. Alle nachfolgend beschriebenen Punkte müssen gegebenenfalls auch im Kontext eines angestrebten DevOps-Ansatzes bearbeitet werden. Hier gilt es zu klären, welche Testautomatisierungstools am besten den gewählten Entwicklungsansatz unterstützen, ob eigenentwickelte Tools weiterverwendet werden können. Darüber hinaus muss betrachtet werden, welche und wie viele Testumgebungen benötigt werden und wie diese mit Testdaten versorgt werden können. Hier ist dann insbesondere die Einbettung der einzelnen Tools und Umgebungen in eine End-to-End-Tool-Pipeline zu beachten.
Das Dach des Hauses bilden die fortgeschrittenen agilen Techniken zur Qualitätssicherung. Hier sind schließlich alle komplexeren Methoden und Techniken anzusiedeln, die sich als Teil der agilen Softwareentwicklung oder in ihrem Kontext herausgebildet haben, wie beispielsweise das Behaviour-Driven Development [Fer14]. Ebenso sind hier aber auch proaktive Quality-Engineering-Ansätze, zum Beispiel Performanzengineering statt nur bloßer Performanztests, anzusiedeln.
Neben der testspezifischen Betrachtung der Inhalte stellen ein auf die agile Transformation angepasstes Veränderungsmanagement und eine gezielte Organisationsentwicklung einen weiteren Erfolgsfaktor dar [Kai17].
Nachfolgend wird nun die Umsetzung des beschriebenen Konzepts bei der Bundesagentur für Arbeit dargelegt.
Die Erfahrungen
Seit dem Jahr 2010 begleitet Accenture gemeinsam mit dem Kunden die agile Reise (siehe Kasten 1). Man sammelte viele Erfahrungen, die im weiteren Verlauf des Artikels näher betrachtet werden sollen. Die vorgestellte Theorie wird anhand von Beispielen aus dem Praxisprojekt demonstriert.
Kasten 1
Im Rahmen der bekannten agilen Skalierungsframeworks wie SAFe© [Math17], NEXUS© [Bit18] oder LeSS© [Lar17] werden viele der im Folgenden beschriebenen Best Practices eingesetzt. Zum Start der Transformation in der damaligen Wasserfallwelt war der Test etabliert. Der Changeprozess hin zum agilen Vorgehen schürte bei den Testern Ängste und Ungewissheiten. Unklare Rollen, Angst vor Auflösung des Testteams, auch die Zusammenarbeit zwischen Entwicklern und Testern und die damit verbundene Auflösung der Silos bargen die Herausforderung, Tester dazu zu motivieren, in die agile Welt zu wechseln.
Das Skillprofil des Testers wandelt sich seit den Anfängen der Agilisierung stark in Richtung eines agilen Quality-Engineers. Der damit verbundene Mindchange, der im ersten Teil theoretisch beschrieben wurde, stellt in der Praxis die größte Herausforderung dar.
Abbildung 2 zeigt den traditionellen Ansatz des Testings sinnbildlich. Die Testaktivitäten konzentrieren sich auf die Testphase im Softwareentwicklungszyklus.
Im Folgenden werden exemplarische Praxisbeispiele für die drei Säulen des House of agile Testing (siehe Abbildung 1) aus dem Beispiel bei der BA beschrieben.
Abb. 2: Traditionelles Testvorgehen
Die Säule „Tools“
Ein Beispiel der Säule „Tools“ aus dem House of agile Testing ist die Umsetzung der aus der Literatur bekannten Testautomatisierungspyramide [Coh09] von Mike Cohn und die damit verbundene Umsetzung vollumfänglicher Testautomatisierung. Wie soll es möglich sein, alle Testaktivitäten aus der „alten Welt“ in nur einem Sprint für das „potentially shippable product“ unterzubekommen?
Viele Beteiligte an Projekten kennen sowohl das Problem als auch die Pyramide. Die zentrale Herausforderung ist jedoch die Umsetzung. Das Prinzip des „shift left“ (siehe Abbildung 3) gibt klare Strukturen dafür vor, wie Testaktivitäten sinnvoll aneinandergereiht werden, um mit einer vorgegebenen Sprintlänge alle nötigen Testaktivitäten umsetzen zu können. Bezug nehmend auf Abbildung 2 werden damit die Testaktivitäten zum frühestmöglichen Zeitpunkt durchgeführt.
Umsetzbar ist das durch ein klares Engagement zur Testautomatisierung. Bei dem Beispielprojekt wurde so über die Jahre eine Testautomatisierungsquote von 95 Prozent über alle Teststufen erreicht.
Abb. 3: Zielbild „shift left“
Die Säule „Menschen und Rollen“
Als Beispiel aus der Säule „Menschen und Rollen“ sind die Strukturierung der organisatorischen Teamstruktur und ihre Aufgabenbereiche zu nennen. Diese Fragestellungen gilt es, im Laufe der Organisationsentwicklung zu klären.
Über die Jahre hinweg wurde das klassische Testteam immer weiter in die agilen Teams überführt. Der Effekt war der, dass Testaktivitäten relativ schlecht abgestimmt einerseits in den Entwicklungsteams (ET) und andererseits im Testteam (TEST) durchgeführt wurden. In einem weiteren Schritt galt es, klare Strukturen dafür vorzugeben, wo und wann welche Testaktivitäten durchgeführt werden. Dem Team muss bewusst werden, dass es alleine für die Qualität seiner Anwendungsbereiche verantwortlich ist und kein weiteres Team ein „Sicherheitsnetz aufspannen wird“.
Unter diesen Voraussetzungen entstand ein selbstverantwortetes Qualitätsverständnis der Teams, das die Identifikation mit dem Produkt stärkt. Das Testteam ist weiterhin als wichtiges QS-Bindeglied für das hybride Vorgehen der BA nötig. Es stellt die Verbindung zu den Schnittstellenpartnern her und kümmert sich um die das Release abschließende Qualitätssicherung. Dazu werden abschließende QS-Maßnahmen durchgeführt, die erst kurz vor dem Go-Live relevant werden. Die Teams können sich dadurch besser auf die Weiterentwicklung des Folgerelease konzentrieren. Abbildung 4 stellt die Aufteilung zwischen den Entwicklungsteams (ET) und dem Testteam und den zeitlichen Ablauf dar.
Abb. 4: Organisatorische Teamstruktur und Aufgabenbereiche
Die Säule „Ansatz“
Um den in der zweiten Säule beschriebenen Lieferansatz und das damit verbundene „Was muss getestet werden?“ zu implementieren, muss die nötige Methodik von jedem einzelnen Mitarbeiter verstanden und gelebt werden. Nur ein sinnvoller und überlegter Change-Ansatz kann hier zum Erfolg führen.
Dem wurde in Form eines dedizierten Qualitätsrelease entsprochen. Dazu hat man bei dem Projekt über 6 Sprints 4 Monate lang ausschließlich das bis dahin entstandene Vorgehen hinterfragt, neu definiert und in den Teams umgesetzt. Best Practices aus den Teams wurden vereinheitlicht und über die Teams hinweg geschult.
Um das entstandene Qualitätskonzept regelmäßig zu hinterfragen und den Input aus den Teams bestmöglich aufzunehmen, wurde auf organisatorischer Ebene eine Test Community of Practice (Test-CoP) eingeführt. Diese entwickelte sich zu einem der zentralen Bestandteile, die zum nachhaltigen Erfolg geführt haben. Im Rahmen dieser CoP werden die Teams aktiv in die Weiterentwicklung des Testvorgehens und der Methodiken eingebunden und damit Anregungen und Ideen teamübergreifend diskutiert, verfeinert und eingeführt. So erreicht man, dass gute Ansätze aus den Teams auf dem gesamten Projekt Anwendung finden und ein übergreifendes Qualitätsverständnis und Qualitätsniveau gehalten werden können.
Fazit
Die genannten Beispiele vermitteln eine Vorstellung davon, welche Faktoren in den vielen Jahren zur Verbesserung der Qualität beigetragen haben. Aus Sicht von Accenture ist der VAM eines der am weitesten entwickelten agilen Projekte. Andere Projekte haben noch eine weite Reise im agilen Umfeld vor sich. Der nächste logische Schritt für den VAM ist eine konsequente Umsetzung des projektübergreifenden Quality Engineering, das weiterhin aktiv gemanagt werden muss. Dazu soll Qualität nicht nur im Test, sondern proaktiv von der ersten Anforderung bis zur endgültigen Lieferung an den Kunden sichergestellt werden. Dieser Zustand kann nur schrittweise über viele Jahre erreicht werden und ist in einem so komplexen Umfeld nie wirklich abgeschlossen.
Referenzen
[Bit18]
K. Bittner, P. Kong, D. West, Mit dem Nexus Framework Scrum skalieren – Kontinuierliche Bereitstellung eines integrierten Produkts mit mehreren Scrum-Teams, Dpunkt.verlag GmbH, 2018
[Coh09]
M. Cohn, Succeeding with Agile, Software Development Using Scrum, Pearson Education, 2009
[Fer14]
J. Ferguson, BDD in Action, Manning, 2014
[ISTQB]
ISTQB Certified Tester Foundation Level Syllabus, siehe:
https://www.istqb.org/downloads/syllabi/foundation-level-syllabus.html
[Kai17]
S. Kainzbauer, W. Brandhuber, Eine Einführung in die Agile Organisationsentwicklung, Sigs Datacom eBook, 2017, siehe:
https://www.sigs-datacom.de/wissen/ebooks/wissen-titel/agile-organisationsentwicklung.html
[Lar17]
C. Larmann, B. Vodde, Large-Scale Scrum – Scrum erfolgreich skalieren mit LeSS, Dpunkt.verlag GmbH, 2017
[Math17]
Ch. Mathis, SAFe – Das Scaled Agile Framework – Lean und Agile in großen Unternehmen skalieren, Dpunkt.verlag GmbH, 2017
