Den agilen Modellen ist gemein, dass Testing wenn überhaupt nur am Rande erwähnt wird. Der Fokus liegt auf den Entwicklern und dem Built-in Quality Ansatz. Dabei wird aber von einer hohen Maturität und einer schon fast idealen Welt ausgegangen. Die Realität sieht leider oft nicht ganz so rosig aus. In diesem Beitrag gehen wir auf die drei grössten Herausforderung mit Testen in einem skalierten Umfeld ein.
Scaled Agile steht für die Skalierung der Agilität auf mehrere Teams (ein Team von agilen Teams), welche an gemeinsamen Produkten oder Lösungen arbeiten. Zusätzlich zu den Teams gibt es in SAFe den Release Train Engineer (RTE), welcher als «super» Scrum Master den Agile Release Train (ART) steuert. Daneben den Product Manager als «super» PO und den System Architect/Engineering als «super» Developer. Nur einen «super» Tester gibt es nicht.
Slow statt Flow
SAFe setzt beim Testen vor allem auf Built-in Quality. Denn in einem agilen Setup hat man weder Zeit noch Ressourcen, um vor der Auslieferung die Qualität rein zu testen und viel Ressourcen für Fehlersuche und Fehlerbehebung aufzuwenden. SAFe unterscheidet 5 Dimensionen:
- Flow durch Test-First Ansatz (TDD, ATDD)
- Code Qualität durch Extreme Programming (XP) Ansätze
- System Qualität durch kontinuierliche Integration (CI)
- Architektur und Design Qualität durch wohldefinierte Schnittstellen und «Test Doubles»
- Release Qualität durch kleine und öftere Releases (CD)
Alles sehr gute Ansätze, welche sich mit dem Prinzip der Testpyramide decken. In der Praxis steht aber bei vielen die Pyramide aus Gründen wie Zeitdruck, fehlenden Tools oder schwerfälligen Legacy Applikationen sogar auf dem Kopf.
Wir haben dann ein Cornet anstelle einer Pyramide und einen Test-Last statt Test-First Ansatz. Dies geht oft einher mit einem tiefen Automatisierungsgrad von Integration, Test und Deployment. Ein Teufelskreis. Aufwendiges manuelles Testen führt zu einem hohen Einführungsrisiko mit wenigen Releases, was wiederum zu schlechter Qualität und noch höherem Testaufwand führt. Will man diese Abwärtsspirale durchbrechen, bleibt einem nichts anderes übrig, als konsequent in den Ausbau einer soweit wie möglich automatisierten DevOps Pipeline mit Continuous Integration (CI), Testing (CT) und Delivery (CD) zu investieren. Kein einfaches Unterfangen, rechnen Sie mit mehreren Monaten oder sogar Jahren für dessen komplette Umsetzung. Auf erste Erfolge muss man jedoch nicht so lange warten, auch kleine Schritte zahlen sich aus.
What Feature?
SAFe hat seinen Ursprung im Buch «Agile Software Requirements» von Dean Leffingwell. Darin wird unter anderem das Epic - Feature - Story Konzept eingeführt. Epics sind Container für ein Lösungsvorhaben, dessen Umsetzung über mehrere Inkremente - Timeboxen von 9-12 Wochen - erfolgt. Epics werden in Features heruntergebrochen. Ein Feature erbringt einen klaren Wert, hat Akzeptanzkriterien und wird innerhalb eines Inkrementes realisiert, integriert und getestet. Das Feature wird analog in Stories heruntergebrochen, welche in einen Sprint passen.
So weit die Theorie. In der Praxis ist es oft so, dass es Features nicht gibt oder nur als Planungs-Container. Oder dann sind sie zu gross beziehungsweise komplex. Es hilft auch nicht, dass Epic und Feature oft verwechselt werden.
Wird es verpasst, in die Qualität der Features zu investieren und gibt es keine testbaren Akzeptanzkriterien, besteht die Gefahr, dass man sich im Gewirr der Stories verzettelt und den gewünschten Wert verfehlt. Denn ein Feature ist mehr als die Summe seiner Stories. Um die Qualität sicher zu stellen, kann man die gleichen Praktiken wie für die Stories anwenden. Eine sauber definierte und eingehaltene Definition of Ready (DoR), das 3C (Card, Conversation, Confirmation) und das Tres Amigos Prinzip.
Team - Toll Ein Anderer Machts
Während es (hoffentlich) klar ist, dass das Team für Integration und Test der Story zuständig ist, je nach dem unterstützt durch einen Embedded Tester, gibt es beim Feature Interpretationsspielraum. Und was ist mit den End-2-End Tests, den übergreifenden Regressionstests und nicht-funktionalen Tests? Die Teams fokussieren meist auf den eigenen Teil und haben keine Zeit (oder Lust) sich um die Systemsicht zu kümmern. Erschwerend kommt hinzu, dass in einem komplexen Umfeld die Teams eher Komponenten als Feature Teams sind. Dadurch werden Schnittstellen untereinander und zu Dritten vernachlässigt. Niemand fühlt sich zuständig, gemeinsam und übergeordnet zu testen.
SAFe kennt mit dem «System Team» ein spezialisiertes Team, welches übergreifend unterstützt und End-to-End Testing Aufgaben übernehmen kann. Immer aber in enger Zusammenarbeit und als Unterstützung der agilen Teams. In das System Team können Feature Tester integriert werden, welche Teile der oben genannten Tests durchführen. Bleibt die Frage, wer die teamübergreifenden Testaktivitäten plant, moderiert und hilft allfällige «Impediments» auszuräumen. Hier kommt der anfangs erwähnte «super» Tester ins Spiel. Nicht im Sinne eines Managers, sondern eines «Servant Leaders», weshalb wir die Bezeichnung Test Master gewählt haben.
Fazit
Testen im skalierten agilen Umfeld kennt viele der gleichen Herausforderungen wie in klassischen Vorhaben. Die bekannten Frameworks liefern theoretische Ansätze, welche aber nicht einfach so umsetzbar sind. Bauen Sie ihre DevOps Pipeline konsequent aus, ebenso iterativ und inkrementell wie die Lösung, welche damit ausgeliefert wird. Investieren Sie in die Qualität der Features, um böse Überraschungen am Ende des Inkrements zu vermeiden. Und definieren Sie, wer für welche Tests zuständig ist, denn Qualität ist immer noch ein Team Sport, auch wenn mehrere Teams zusammenspielen.
Haben Sie spezifische Fragen zu Scaled Agile Testing oder SAFe? Dann hinterlassen Sie einen Kommentar oder kontaktieren Sie uns direkt. Wir unterstützen Sie mit Coaching, Ausbildung und erfahrenen Spezialisten.
