2

AGILES QUALITY ENGINEERINGAGILES QUALITY ENGINEERING

Die Themen Scrum, agiles Manifest und Lean Software Development wurden in den 2000er-Jahren immer bekannter. 2010 be-gann Accenture die „agile Reise“ bei der Bundesagentur für Arbeit (BA). Auch heute noch ist die Einbindung von Tests und QS in agile Frameworks, gerade in der Anfangsphase, eine besondere Herausforderung aufgrund organisatorischer Änderungen, vie-ler Anpassungen in den Arbeitsprozessen und kürzerer Entwicklungszyklen. Im ersten Teil des Artikels wird das theoretische Fundament gelegt, um dann im zweiten Teil den Bezug zum eingangs genannten Praxisprojekt und zu den dort gesammelten Erfahrungen herzustellen.

»Qualitätssicherung im Kontext von grossen agilen softwareentwicKlungsprojeKten«

Im Rahmen einer agilen Transformation müs-sen wie bei jedem größeren Veränderungs-projekt 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ände-rung zu legen.

„House of agile Testing“

Erfahrungsgemäß sollten mindestens die fol-genden Fragen beantwortet werden:

› Was wollen wir erreichen? (Welches ge-schä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 Zie-le zu erreichen und die Erwartungen zu erfüllen und sie dauerhaft in die Organi-sationsstruktur 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 Ori-entierungshilfe, um alle wesentlichen Punkte im Bereich Test im Auge zu behalten. Für alle weiteren an der Softwareentwicklung be-

teiligten 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, Review-techniken und Defektmanagement (vgl. [IST-QB]).

Die Säulen des Hauses definieren die Ar-beitsweise/Prozesse des Tests in einem agi-len Umfeld. Abbildung 1 stellt die Inhalte der drei Säulen detaillierter dar.

Mit der detaillierten Beschreibung des In-halts dieser drei Säulen allein ließe sich

NICO LIEDL UND THOMAS KARL

Abb. 1: House of agile Testing

02-12_GTM_Sonderdruck_2_2018_accenture.indd 2 17.01.19 10:35

3

AGILES QUALITY ENGINEERING

schon ein ganzes Buch füllen. Nachstehend wird daher nur kurz auf die wesentlichen In-halte 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 Softwareentwick-lungs- beziehungsweise Skalierungsmethode ab, andererseits aber auch von der Frage, ob gegebenenfalls Spezialrollen für den Test be-nö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 wer-den 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 organi-satorischen Strukturen weiterzuentwickeln und letztlich die neuen beziehungsweise an-gepassten Rollen im Organigramm der Orga-nisation 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 komple-xen 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 wer-den 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 beschriebe-nen Punkte müssen gegebenenfalls auch im Kontext eines angestrebten DevOps-Ansat-zes 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 wer-den können. Hier ist dann insbesondere die Einbettung der einzelnen Tools und Umge-bungen in eine End-to-End-Tool-Pipeline zu beachten.

Das Dach des Hauses bilden die fortgeschrit­tenen agilen Techniken zur Qualitätssiche-rung. Hier sind schließlich alle komplexeren Methoden und Techniken anzusiedeln, die sich als Teil der agilen Softwareentwick-lung oder in ihrem Kontext herausgebildet haben, wie beispielsweise das Behavi-our-Driven Development [Fer14]. Ebenso

sind hier aber auch proaktive Quality-En-gineering-Ansätze, zum Beispiel Performanz- engineering statt nur bloßer Performanz-tests, anzusiedeln.

Neben der testspezifischen Betrachtung der Inhalte stellen ein auf die agile Transforma-tion angepasstes Veränderungsmanagement und eine gezielte Organisationsentwicklung einen weiteren Erfolgsfaktor dar [Kai17].

Nachfolgend wird nun die Umsetzung des beschriebenen Konzepts bei der Bundes-agentur 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 Er-fahrungen, die im weiteren Verlauf des Arti-kels näher betrachtet werden sollen. Die vor-gestellte Theorie wird anhand von Beispielen aus dem Praxisprojekt demonstriert.

Im Rahmen der bekannten agilen Skalierungs-frameworks 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 Zusam-menarbeit zwischen Entwicklern und Testern und die damit verbundene Auflösung der Si-los 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 Rich-tung eines agilen Quality-Engineers. Der da-mit 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 Soft-wareentwicklungszyklus.

»Das UmfelD virtUeller arbeitsmarkt (vam)«

Bei der BA werden im Projekt „virtueller Ar-beitsmarkt“ (VAM) zwei Anwendungen ent-wickelt. Auf der einen Seite die Jobbörse, ein externes Portal, über das Arbeitgeber und Arbeitssuchende Profile einstellen und verwal-ten können. Hier kann man Suchen ausführen und selbstständig nach Arbeitsstellen bezie-hungsweise Arbeitskräften suchen. Auf der anderen Seite steht die Anwendung VERBIS. Diese interne Software wird in den Jobcentern und Arbeitsagenturen verwendet, um Arbeits-suchende und Arbeitgeber zu vermitteln und zu beraten. Über 100.000 Mitarbeiter in den Arbeitsagenturen erzeugen so ca. 40 Mio. Sei-tenaufrufe pro Tag.

Derzeit werden die Anwendungen in 16 agilen Teams entwickelt, die seit 2011 schrittweise aufgebaut wurden. Eine der größten Heraus-forderungen ist es, dass der VAM im Umfeld der IT-Systemlandschaft mit 19 internen sowie externen Schnittstellensystemen im Verbund steht. Diese werden zu großen Teilen im Was-serfall entwickelt. Das führt dazu, dass die Entwicklung im hybriden Umfeld stattfinden muss, das mit drei Releases im Jahr keine reine Agilität zulässt.

Kasten 1

Abb. 2: Traditionelles Testvorgehen

02-12_GTM_Sonderdruck_2_2018_accenture.indd 3 17.01.19 10:35

4

AGILES QUALITY ENGINEERING

Im Folgenden werden exemplarische Praxis-beispiele für die drei Säulen des House of agile Testing (siehe Abbildung 1) aus dem Beispiel bei der BA beschrieben.

Die Säule „Tools“

Ein Beispiel der Säule „Tools“ aus dem House of agile Testing ist die Umsetzung der aus der Literatur bekannten Testautomatisierungs­pyramide [Coh09] von Mike Cohn und die damit verbundene Umsetzung vollumfängli-cher Testautomatisierung. Wie soll es mög-lich 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 zen-trale Herausforderung ist jedoch die Um-setzung. Das Prinzip des „shift left“ (siehe Abbildung 3) gibt klare Strukturen dafür vor, wie Testaktivitäten sinnvoll aneinander-gereiht werden, um mit einer vorgegebenen

Sprintlänge alle nötigen Testaktivitäten um-setzen zu können. Bezug nehmend auf Abbil-dung 2 werden damit die Testaktivitäten zum frühestmöglichen Zeitpunkt durchgeführt.

Umsetzbar ist das durch ein klares Engage-ment zur Testautomatisierung. Bei dem Bei-spielprojekt wurde so über die Jahre eine Testautomatisierungsquote von 95 Prozent über alle Teststufen erreicht.

Die Säule „Menschen und Rollen“

Als Beispiel aus der Säule „Menschen und Rollen“ sind die Strukturierung der organisa­torischen Teamstruktur und ihre Aufgabenbe­reiche 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 Testak-tivitäten relativ schlecht abgestimmt einer-

seits in den Entwicklungsteams (ET) und an-dererseits im Testteam (TEST) durchgeführt wurden.

In einem weiteren Schritt galt es, klare Struk-turen 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 Verbin-dung zu den Schnittstellenpartnern her und kümmert sich um die das Release abschlie-ßende Qualitätssicherung. Dazu werden ab-schließende QS-Maßnahmen durchgeführt, die erst kurz vor dem Go-Live relevant wer-den. Die Teams können sich dadurch besser

Abb. 3: Zielbild „shift left“

Abb. 4: Organisatorische Teamstruktur und Aufgabenbereiche

02-12_GTM_Sonderdruck_2_2018_accenture.indd 4 17.01.19 10:35

5

AGILES QUALITY ENGINEERING

auf die Weiterentwicklung des Folgerelease konzentrieren. Abbildung 4 stellt die Auftei-lung zwischen den Entwicklungsteams (ET) und dem Testteam und den zeitlichen Ablauf dar.

Die Säule „Ansatz“

Um den in der zweiten Säule beschriebe-nen Lieferansatz und das damit verbundene „Was muss getestet werden?“ zu implemen-tieren, 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 Quali­tä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 regel-mäßig zu hinterfragen und den Input aus den Teams bestmöglich aufzunehmen, wurde auf organisatorischer Ebene eine Test Commu­nity of Practice (Test-CoP) eingeführt. Diese entwickelte sich zu einem der zentralen Be-standteile, die zum nachhaltigen Erfolg ge-führt haben. Im Rahmen dieser CoP werden die Teams aktiv in die Weiterentwicklung des Testvorgehens und der Methodiken ein-gebunden und damit Anregungen und Ide-en 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 übergrei-fendes Qualitätsverständnis und Qualitätsni-veau 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 entwi-ckelten agilen Projekte. Andere Projekte ha-ben 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 sicher-gestellt werden. Dieser Zustand kann nur schrittweise über viele Jahre erreicht wer-den 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

Thomas Karlthomas.karl@accenture.comist spezialisierter Agile Coach und Advisor mit Schwerpunkt auf Qualitätsmanagement, insbesondere Testautomatisierung, Prozessver­besserung und organisatorischem Wandel. Er hat Erfahrungen bei verschiedenen komplexen Großprojekten gesammelt. Als Anwender, Trainer und Coach befasst er sich umfassend mit agilen Methoden wie Lean Six Sigma, SAFe, Scrum und Kanban.

Nico Liedlnico.liedl@accenture.comist Quality­Engineer und Advisor mit Schwerpunkt auf agilem Qualitätsmanagement, Testautomatisierung, Prozessverbesserung und orga­nisatorischem Wandel. Er hat Erfahrungen bei verschiedenen komplexen Großprojekten gesammelt. Als Teammitglied, Scrum­Master, Teststratege, Releasemanager und Trainer hat er praktische Erfahrung und theoretisches Fachwissen zu bieten und möchte sie mit einem breiten Publikum teilen.

02-12_GTM_Sonderdruck_2_2018_accenture.indd 5 17.01.19 10:35