Development Testing Agility

Ein Test-Evaluierungsmodell als Lösung zur Weiterentwicklung für agile Teams?

Die Raiffeisen Bank International AG (RBI) begann 2014 mit der Umstellung der Projektabwicklungen von einem klassischen Ansatz, mehrheitlich nach dem Wasserfallmodell, in einen agilen Ansatz. Dies ergab nicht nur Änderungen für Projektteams, sondern auch konkret für das Berufsbild der Tester im Unternehmen. Aus unabhängigen Testteams wurden agile Teams, welche aus Entwicklern, Testern und Fachbereichs-Mitarbeitern bestehen. Diese Ausrichtung trägt dem Whole-Team-Approach Rechnung. Unterstützung fanden die Teams dabei durch Agile Engineering Coaches, welche durch ein selbst entwickeltes Test-Reifegradmodell (Agile Engineering Maturity Modell, kurz AEMM) den Teams eine Evaluierung und Verbesserung ihrer Engineering-Fähigkeiten im Bereich Test ermöglichen.

Christa Gegendorfer

Author

Martin Rohr

Author

27.11.2020
Lesezeit: 9 Minuten
22 Views

Diese Neuausrichtung wurde 2019 komplett umgesetzt und brachte die Herausforderung, Testen gemeinsam wahrzunehmen und sich als (neues) Team weiterentwickeln zu wollen. Die Evaluierung wurde mittlerweile auf das gesamte RBI-Headoffice ausgeweitet. Bisher nahmen 50 Prozent aller Teams im Headoffice an der Befragung teil. Zurzeit bereiten die Agile Engineering Coaches die Ausweitung auf den RBI-Gesamtkonzern in CEE (Central and Eastern Europe) vor.

Dieser Artikel gibt einen Einblick, wie das Reifegradmodell entwickelt und angewendet wird, und zeigt den Nutzen für die Teams auf.

Hintergrund für den Bedarf des AEMM

Schon vor dem Start der Transformation der Projektabwicklung zum agilen Ansatz war absehbar, dass die Engineering-Skills in den jeweiligen Teams stark abweichen. Das sollte näher beleuchtet werden. Ferner wollte das Management unter dem Titel „Agile Investment“ die agilen Teams auch mit Geldund Zeit-Budget unterstützen, um neue Technologien, Tools und Methoden einzuführen („Upskilling“).

Ziel waren vor allem sehr alte („legacy”) und historisch gewachsene Applikationen und die zugehörigen Teams. Die übergeordneten Ziele sind ein Mindeststandard für die vier Bereiche CI/CD, DevOps, Test und Testautomation und weiters die Möglichkeit, die Umsetzung von Verbesserungen über die Zeit bewerten zu können.

Entwicklung des Modells AEMM, Version 1

Basis für die Bereiche „Testing” und „Test Automation” des AEMM waren die Modelle TPI NEXT® (Sogeti, [TPI]) und TMMi (Test Maturity Model integration, [TMMi]). Nach einigen Testläufen mit Pilotteams wurde eine adaptierte Variante des TPI Next namens Agile TPI® (Sogeti) ausgewählt.

Für die Bereiche DevOps und CI/CD wurde das Reifegradmodell der Standard-Bank als Basis verwendet. Für alle vier Teilbereiche wurde schlussendlich ein einfacher gemeinsamer Bewertungsansatz in drei Reifegradstufen (Crawl-Walk-Run) analog des DevOps Maturity Model der Firma Adidas [GitH] gewählt (siehe Tabelle 1).

Tabelle 1: Beispielkategorie on AEMM, Version 1 „Test Analysis & Design“ mit Fragen und zugehörigen Reifegradstufen (Crawl, Walk, Run)

Im Zuge einer mehrmonatigen Pilotphase wurden Erfahrungen gesammelt und schlussendlich die Fragen für die Version 1 so adaptiert, dass sie möglichst allgemeine Gültigkeit haben. Eigen- und Fremdentwicklungen werden gleichermaßen unterstützt. Auch unterschiedliche Technologien müssen vergleichbare Ergebnisse erzielen.

Erhebung des Test-Status-quo

In AEMM, Version 1 werden in einem zweistündigen Interview ca. 150 Fragen in 27 detaillierten Kategorien beleuchtet. Enthalten sind auch Fragen zu CI/CD und DevOps, der Artikel geht aber nur auf Test-relevante Fragen ein. Diese decken Themen wie Test-Design, Testautomation, Soft Skills usw. ab. In der Auswertung wird jeder Fragenkategorie ein Reifegrad auf Basis der Einzelfragen pro Kategorie zugewiesen: „Crawl“ (Must be), „Walk“ (Should be) oder „Run“ (Could be).

Ziel ist es, den Teams einen Überblick über den Status quo zu geben sowie Verbesserungspotenziale aufzuzeigen. Die Auswertung des Fragebogens erfolgt in einem einseitigen Executive Summary durch Agile Engineering Coaches. Die Ergebnisse der einzelnen Kategorien werden aggregiert dargestellt und es werden Empfehlungen zur Verbesserung ausgesprochen (siehe Abbildung 1). Betrachtet werden auch potenzielle Auswirkungen bestimmter Maßnahmen auf das Business.

Abb. 1: Gesamtüberblick über die drei Stufen eines Interviews mit einem Product Team – vom Fragebogen über die Summary zum Fragebogen bis zur Executive Summary

Alle Vorschläge werden in einem zweiten Gespräch mit den verantwortlichen Teammitgliedern abgestimmt. Bei Bedarf werden dann Maßnahmen ergänzt oder neu bewertet. Die Umsetzung erfolgt grundsätzlich in Eigenverantwortung durch die jeweiligen Teams. Falls gewünscht, arbeitet ein Agile Engineering Coach einige Zeit im Team mit.

Herausforderungen bei der Evaluierung

Erhebungen jeglicher Art sind für die befragten Teams oft mit Vorbehalten behaftet, weil ein Vergleich mit anderen Teams befürchtet wird. Eine übertrieben positive Darstellung der Ist-Situation ist oft die Folge. Deswegen wird mehrfach die stark eingeschränkte Vergleichbarkeit der Ergebnisse zwischen den Teams betont. Zusätzlich werden die Fragen bereits im Vorfeld versendet und es wird die Auswertungslogik erklärt. Die Ergebnisse (Executive Summary) der Teambefragungen werden für Auswertungen anonymisiert und aggregiert.

Erkenntnisse für Teams, Coaches und Management

Eine der wohl spannendsten Erkenntnisse mit Version 1 war, dass viele Teams von sich aus an einem Agile Engineering Maturity Model Interesse zeigen. Das Interesse war bereits in der Pilotphase absehbar – unter anderem an den Diskussionen im Zuge der Befragung.

Teams erkennen den Nutzen, wenn sie sich in ihrem „eigenen Test-Status-quo“ wiederfinden und die mit ihnen erarbeiteten Verbesserungsvorschläge in ihr Team-Backlog übernehmen können. Für viele Teams entstehen durch die umfassende Abdeckung der Test-Thematik im AEMM wichtige neue Ideen zur Verbesserung. Ein Mehrwert für ein Team kann beispielsweise ein Aufgreifen von agilen Testmethoden sein oder die Optimierung der Qualität der Testdaten. Für Coaches gibt es durch die Interviews laufend Rückmeldung zum Modell selbst, sodass dieses weiter verbessert werden kann.
Für das Management werden auf aggregierter Ebene (siehe Abbildung 2) in den jeweiligen Kategorien nach einer größeren Anzahl an Interviews ähnliche Muster oder Trends erkennbar, beispielsweise bei der durchgängigen Umsetzung des Whole-Team-Approachs in der Testautomation. Auf Basis dieser Muster kann das Management Team-übergreifende Maßnahmen beschließen.

Abb. 2: Aggregation der AEMM-Ergebnisse über eine Vielzahl an Product Teams

Teams erhalten mit der Executive Summary eine Basis für Verhandlungen mit dem Management oder Product Owner, um für die Verbesserung ihrer Testaktivitäten die benötigte Priorität im Team-/Product-Backlog zu bekommen. Ein Beispiel wäre die Integration von Testautomationsaktivitäten in eine CI/ CD-Pipeline.

Ergebnisse der Evaluierung

Nach der Durchführung von ca. 30 Interviews mit AEMM, Version 1 konnten die folgenden Kernthemen ermittelt werden:

Im Bereich Testansatz

Abbildung 3 fasst die Ergebnisse zusammen. Wichtige Test-Methoden wurden nur teilweise oder nicht angewendet, zum Beispiel die Durchführung nicht-funktionaler Tests, explorativer Tests oder risikobasierte Testdurchführung. Test-Dokumentation war veraltet und entsprach nicht den firmeninternen Mindeststandards, zum Beispiel waren Test-Strategien nicht mit Produkt-Risiken abgestimmt oder Testfälle wurden nicht im firmeninternen Testmanagement-Tool verwaltet. Auch Test-Skills waren nach der agilen Transformation noch nicht in allen Abteilungen ausreichend aufgebaut, der Whole-Team-Approach konnte nicht überall umgesetzt werden. Auf sich alleingestellte Test-Experten, Teams ohne Test-Automations-Know-how sowie unzureichende Testdaten-Qualität sind konkrete Folgen davon.

Abb. 3: Häufigste gefundene Kernthemen/Problembereiche im Bereich Testing/Testansatz nach 30 Interview

Im Bereich Testautomation

Die Testfalldurchführung war in einigen Teams nur teilweise automatisiert – nur Tests für einzelne Komponenten (z. B. Backend, Frontend) automatisiert, Regressionstests nur teilweise automatisiert (siehe Abbildung 4). Der Whole-Team-Approach war manchmal nur zum Teil umgesetzt – ein hoch spezialisiertes Testframework wird von einem einzigen Teammitglied „bedient“, das Testfalldesign und die Testfallentwicklung werden ausschließlich von Testern durchgeführt, jedoch nicht auch vom Fachbereich oder von Entwicklern. In drei Teams gab es keine Testautomation. In anderen Teams wurden alle Tests automatisiert, jedoch noch nicht in die CI-Pipeline eingebunden. Hinsichtlich Testautomations-Methodik waren in einem Team die Aufwände der Testautomation nicht dokumentiert, eine Kosten/ Nutzen-Analyse für zu automatisierende Testfälle fehlte.

Abb. 4: Häufigste gefundene Kernthemen/Problembereiche im Bereich Testautomation nach 30 Interviews

Anpassung des Evaluierungsvorgehens mit AEMM, Version 2

Nach den ersten 30 Interviews mit Product Teams wurden in einer Retrospektive der Agile Engineering Coaches mehrere Problembereiche betreffend Inhalt und Ablauf genannt.

Das wichtigste Problem war, dass der geplante Zeitrahmen von zwei Stunden in 90 Prozent der Interviews überzogen wurde. Die längsten Interviews dauerten in Summe bis zu 5 Stunden. Grund war meist verlorene Zeit durch Erklärungen des Modells an sich und Detaildiskussionen zur Auslegung einzelner Fragen. Da die Zeit für die Interviews nicht verlängert werden sollte, war eine Strukturänderung notwendig. Nun stehen immer drei Fragen – je eine für jede Reifegradstufe – nebeneinander in einer Zeile (siehe Tabelle 2).

Tabelle 2: Beispielkategorie in der neuen Struktur, Version 2.0

Das zweite Hauptproblem waren widersprüchliche Endergebnisse. Durch die Möglichkeit, Fragen unabhängig voneinander mit „JA“ oder „NEIN“ zu beantworten, entstanden mehrfach Situationen, wo Fragen für höhere Reifegradstufen positiv beantwortet wurden, verwandte Fragen für niedrigere Reifegradstufen hingegen negativ. Deswegen wurden die Einzelfragen von Fragengruppen besser abgestimmt, zusätzlich wurden viele Fragen überarbeitet. Die Verbesserungen sind nun mit der Version 2.0 des AEMMs umgesetzt.
In ersten Probeläufen wurde eine Reduktion der benötigten Zeit auf 40 bis 60 Prozent gemessen und die Ergebnisse scheinen auf den ersten Blick gleich gut zu bleiben. Es besteht aber die Befürchtung, dass die neue Struktur mittelfristig zu einer Tendenz der Einordnung in der Mitte – dem Reifegrad Walk – führt und damit die Ergebnisse verfälscht.
Abgesehen davon gibt es weitere kleinerer Probleme. Interviews waren manchmal wegen falscher Teilnehmer wenig aussagekräftig. Andere Teams betreiben offensichtliches Overselling, was insofern ein Problem darstellt, weil das Team entweder eine falsche Selbsteinschätzung hat oder aber das AEMM als unerwünschte Einmischung betrachtet. In beiden Fällen ist eine selbstständige Verbesserung des Teams fraglich.

Um auch diese Probleme zu entschärfen, wird zukünftig die Auswahl der Teilnehmer aus den Product Teams genauer hinterfragt. Das Thema „overselling“ soll durch kürzere Wiederholungsintervalle für neuerliche AE-MM-Interviews adressiert werden.

Abschließend war noch die lange Durchlaufzeit für die Nachbearbeitung der Interviews ein Thema. Dadurch geriet für alle Beteiligten der Interview-Termin in Vergessenheit, was die Diskussion über Findings und Verbesserungsmaßnahmen erschwerte. Die Agile Engineering Coaches haben sich nun eine Frist von 1 bis 2 Wochen für die Nacharbeit gesetzt.

Fazit

Das AEMM ist ein Beispiel, wie mit einem Test-Reifegradmodell ein Mehrwert für Teams, Agile Engineering Coaches und auch das Management beziehungsweise das Unternehmen selbst geschaffen werden kann. In diesem Fall hat sich der Aufwand für das an das Unternehmen angepasste Modell gelohnt! Wenn die agilen Teams dadurch Optimierungen umsetzen, steigen insgesamt die Effizienz und Effektivität.