Oft werden wir mir der Frage konfrontiert: wie soll das Testen in einem skalierten agilen Umfeld organisiert werden?
Dieser Frage möchte ich im Kontext von SAFe nachgehen. Nicht zufällig. Gemäss der Xebia Trends und Benchmarks Studie ist SAFe das am weitesten verbreitete Modell für skalierte Agilität. Mit ein Grund dafür ist der einfache Zugang zu den Informationen auf der Webseite von Scaled Agile Framework und das breite Ausbildungsangebot. Vorteil von diesem grossen Informationsangebot ist, dass es zu fast jedem Thema Inhalte gibt. Nachteil ist, dass es teilweise schwierig ist diese auch zu finden (und noch schwieriger ist, diese erfolgreich anzuwenden). So fällt auf den ersten Blick auf, dass "Test" auf dem Big Picture nicht erwähnt wird. Doch bevor wir zum Testing kommen, nachfolgend noch ein paar Worte zum SAFe Framework.
Das SAFe Framework in Kürze
Ich beziehe mich hier auf Essential SAFe, welches das Grundelement aller Konfigurationen und somit aller SAFe Implementationen ist. Wenn schon bekannt, bitte überspringen
Quelle und Copyright: Xebia
Die Basis bilden die cross-funktionalen agilen Teams, welche User Stories nach den bekannten Grundsätzen von Scrum oder Kanban umsetzen. Alle Teams, die gemeinsam ein Produkt oder eine Lösung entwickeln, werden in einem Agile Release Train (ART) zusammengefasst und folgen der gleichen Iterationskadenz, also synchronen 2-4 Wochen Sprints. Die Planung im ART erfolgt in Programm Inkrementen (PI); 8-12 Wochen lang. Dabei werden zu Beginn im Rahmen des PI-Planning team-übergreifend Features in User Stories aufgespalten, mit der vorhandenen Kapazität abgeglichen und Abhängigkeiten erkannt und gemanaged. So wie User Stories innerhalb eines Sprints umgesetzt (und getestet) werden, werden Features innerhalb eines PI umgesetzt (und getestet) und im Rahmen von System Demos vorgeführt. Zusätzlich zu den Team Rollen gibt es in SAFe den Release Train Engineer (RTE), welcher als Servant Leader und Coach für den ART fungiert. Daneben den Product Manager, zuständig für Vision, Roadmap und Features des Programmes, und den System Architect/Engineering, verantwortlich für die Definition und Vermittlung einer gemeinsamen technischen und architektonischen Vision. Soweit zum Framework.
Built-in Quality
SAFe setzt beim Testen vor allem auf Built-in Quality. 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. Die Qualität muss zudem in jedem Sprint und in jedem Inkrement sichergestellt werden, wodurch sich der Aufwand für Test und Debugging schnell multiplizieren kann. SAFe unterscheidet 5 Dimensionen:
Flow: Tests sind Teil des Flows und werden früh, oft und auf verschiedenen Ebenen durchgeführt. Der Schlüssel dafür ist der Test-First Ansatz. Auf Ebene Code mit Test Driven Development (TDD), auf Ebene User Stories und Features mit Behavior-Driven Development (BDD), basierend auf gemeinsam erarbeiteten Akzeptanzkriterien. Zudem ist ein hoher, stufengerechter Automatisierungsgrad anzustreben, integriert in eine durchgehende Delivery Pipeline.
Architektur und Design Qualität: Eine hohe Qualität von Architektur und Design sind sehr wichtig für die Testbarkeit eines Systems. Modulare Komponenten, die über wohldefinierte Schnittstellen kommunizieren, ermöglichen es fehlende oder instabile Komponenten durch "Test Double" (Dummy, Mocks, Stubs) zu ersetzen.
Code Qualität: Eine hohe Codequalität bildet die Basis für ein einfaches und schnell erweiterbares System und reduziert die Fehleranfälligkeit. Es empfiehlt sich, altbekannte und bewährte Extreme Programming (XP) Ansätze wie TDD, Pair Work und Collective Code Ownership konsequent anzuwenden.
System Qualität: Um das Systemverhalten zu testen, verweist SAFe auf den oben genannten Flow, mit einer kontinuierlichen Integration (CI) als Teil der Delivery Pipeline. Dabei dürfen Tests der nicht-funktionalen Anforderungen nicht vergessen werden.
Release Qualität: Je schneller ein Feature ausgeliefert werden kann, desto schneller kann dessen Nutzen validiert werden. Es werden also kleinere und dafür öfter erfolgende Releases angestrebt, mit dem Ziel das Einführungsrisiko klein zu halten. Eine strikt angewandte Definition of Done (DoD) auf Ebene Team, Inkrement und Release stellt sicher, dass der versprochene Nutzen auch geliefert wird und keine halbfertigen Funktionen ihren Weg in die Produktion finden
Verantwortlichkeiten
Eine Tester Rolle wird in SAFe nicht erwähnt, aber auch nicht explizit ausgeschlossen. Das agile Team ist per Definition cross-funktional aufgestellt und somit auch für das Testing seiner Erzeugnisse verantwortlich. Das System Team ist ein spezialisiertes Team, welches übergreifend unterstützt, zum Beispiel bei der Bereitstellung der Toolchain für die Delivery Pipeline. Das System Team kann End-to-End Testing Aufgaben übernehmen, aber immer in enger Zusammenarbeit und als Unterstützung der agilen Teams.
Fazit
SAFe adressiert Testing vor allem auf Ebene Team und mit einer durchgehenden Delivery Pipeline. Damit wird von einer hohen Maturität und einer schon fast idealen Welt ausgegangen. Die Realität sieht leider oft nicht ganz so rosig aus und es braucht pragmatische Lösungsansätze für das Testing. Eine besondere Herausforderung stellt das Testing der Features dar, vor allem wenn diese von mehreren Teams umgesetzt werden.
Haben Sie spezifische Fragen zu Scaled Agile Testing oder SAFe? Wir unterstützen Sie mit Coaching, erfahrenen Spezialisten und unserem Kurs Scaled Agile Testing.
