Das „House of agile Testing (i. F.: HoaT) liegt inzwischen in der Version 3.0 vor (siehe Abbildung 1). Es setzt sich aus fünf Teilbereichen zusammen: Die Basis bilden die methodischen Ansätze. Auf diesem Testfundament baut der Assessmentbereich auf. Darauf stehen die Säulen „Rollen“, „Ansatz“ und „Tools und unterstützende Maßnahmen“, die das Haus mit „Lean Agile Quality Engineering Methoden“ vervollständigen.
Abb. 1: „House of Agile Testing“
Die Säule „Rollen“ stellt die Frage nach zukünftigen Rollen, Qualifikation der Mitarbeiter und der Entwicklung der organisatorischen Strukturen. Die Säule „Tools und unterstützende Maßnahmen“ hingegen betrachtet infrastrukturelle Themen, wie die Strukturierung der Testumgebungen, die Versorgung mit Testdaten und welches Automatisierungstool am besten wie in eine DevOps-Pipeline zu integrieren ist.
Säule 2 „Ansatz“
Die Vision für das Qualitätsvorgehen von großen Softwareentwicklungsvorhaben steht bewusst im Zentrum des HoaT. Diese ist bereits zu Projektstart (im Greenfield-Ansatz) oder zum Beginn einer Transformation (Brownfield-Ansatz) zu einem operationalisierbaren Plan herunterzubrechen. Dabei ist es elementar, die Qualitätssicherung in den gegebenen Rahmenbedingungen des Projekts beziehungsweise Entwicklungsvorgehens einzuordnen. Meist gibt es, neben dem gewünschten Idealbild für ein agiles oder skaliert agiles Vorgehen, einige Besonderheiten zu berücksichtigen. Diese beziehen sich beispielsweise auf die Lieferzyklen über unterschiedliche Projekte oder Teamkonstellationen hinweg und darin bereits vorhandenes Spezialwissen, welches sich nicht unmittelbar in die Entwicklungsteams integrieren lässt. Genau diese Gegebenheiten müssen erkannt, bewertet und zum Idealbild passend eingeordnet werden. Die Wichtigkeit einer derartigen Bewertung in Säule 2 wächst nicht nur mit der Größe des Entwicklungsvorhabens, sondern auch mit der Komplexität der IT-Systemlandschaft überproportional an.
Der erste Schritt in Richtung Agilität ist stets, das agile (Skalierungs-)Framework zu finden, welches am besten zur Organisation und deren spezifischen Aufgaben passt. Abhängig von der Größe und Komplexität der Organisation, des Entwicklungsvorhabens und der IT-Systemlandschaft usw. gilt es also, sich zwischen Scrum, Kanban, SAFe®, LESS, dem Spotify Model und vielen weiteren Vorgehensweisen zu entscheiden. Dabei wird meistens die Frage diskutiert, ob ein gängiges agiles Modell passt oder ob eine unternehmensspezifische Eigenentwicklung die bessere Option ist?
Die Antwort ist individuell und sollte die Themen Qualitätsanforderungen, -ansatz und einzuhaltende -standards bereits berücksichtigen. Denn es gilt einerseits sicherzustellen, dass regulatorische sowie gesetzliche Anforderungen eingehalten werden, andererseits auch Kundenerwartungen und die Volatilität dieser bei der Methodenauswahl zu berücksichtigen. Ebenso ist es relevant, gegebenenfalls anfallende Folgeinvestitionen im Bereich Qualitätsmanagement einzubeziehen. Dies können Investitionen aufgrund von technisch, methodisch oder organisatorisch notwendigen Veränderungen sein, wie dem Insourcing eines ausgelagerten Testcenters.
In der Säule „Ansatz” sind zwei unterschiedliche Herangehensweisen zur Qualitätssicherung hervorzuheben, da bei der Transformation insbesondere die Integration der Funktionalitäten über die Teams hinweg betrachtet werden muss. Konkret ist das der
- „In-Sprint-Delivery“-Ansatz” vs.
- „Cross-Sprint-Delivery“-Ansatz”.
Im Vergleich zu herkömmlichen Testprozessen ist das primäre Ziel, so viele QM-Aufgaben (proaktiv und reaktiv) wie möglich und sinnvoll innerhalb des Teams im Sprint zu verankern. Damit lässt sich der Mind-Change und der oft zitierte Built-in-Quality-Ansatz in den Köpfen der Mitarbeiter festigen. Die Teams bekommen die Möglichkeit, Aktivitäten mitzugestalten und selbst zu entscheiden, wann sie diese einplanen und durchführen. Dennoch kann es Situationen geben, in denen eine Qualitätssicherung kurz- oder langfristig nicht nur innerhalb eines Sprints umsetzbar oder sinnvoll ist.
Beide Varianten sind prinzipiell eine Option, solange es sich dabei um eine bewusste Entscheidung im Einklang mit allen Beteiligten, allen Vorgaben und Regeln, den gesetzten Zielen und einer klaren Verteilung der QM-Verantwortung handelt. Insbesondere bei einer Bottom-up-Einführung von Agilität lässt sich dies oftmals gar nicht vermeiden, wie unsere Erfahrung in unterschiedlichsten Projekten zeigen.
Projektbeispiel
Kontext: Großunternehmen mit mehreren Tausend Mitarbeitern in der IT und mehreren Dutzend verschiedenen Softwareentwicklungsprojekten. Die Befugnisse des Projektleiters beschränken sich auf sein Projekt.
Aktuelle Entwicklungsmethode: V-Modell
Projektgröße: Ca. 100 Personen (Entwickler, Business-Analyse, Test- und Projektmanagement)
Zielbild: Agile Transformation mit dem Brownfield-Ansatz ohne Beeinträchtigung des Produktionsbetriebs während der Projektlaufzeit. Der Projektleiter hatte in diesem Fall zwar die Entscheidungshoheit, die Softwareentwicklungsmethode in seinem Projekt zu verändern, jedoch keinerlei Einflussmöglichkeit auf andere Projekte oder Bereiche. Ebenso musste er sich innerhalb der unternehmensweit geltenden Vorgaben hinsichtlich des Toolings bewegen. In einer solchen Konstellation ist es nicht möglich, unternehmensweit eine agile Transformation zu initiieren, weil für andere Projekte nicht mitentschieden werden kann. Hier hat es sich bewährt, das Vorgehen so weit wie möglich dem Idealbild anzunähern und dann als gutes Beispiel in die Gesamtorganisation wirken zu lassen.
Meilensteine: Im Folgenden geben wir einen Einblick in die Meilensteine, die in der Nachbetrachtung den meisten Einfluss auf den Erfolg der Transformation der Testprozesse hatten:
- Langfristiges aktives Changemanagement: Halbherzige Aktivitäten, die nicht im gesamten Projekt Ernsthaftigkeit erfuhren, scheiterten und schädigten langfristig die Motivation. Professionelles Changemanagement verkürzte den Weg zu selbstorganisierten Teams. Das führte schließlich zu intrinsisch motivierter Prozessverbesserung über den gesamten Testprozess hinweg. Role Model Canvas und aktive Management-Unterstützung waren Schlüsselwerkzeuge im Beispielprojekt.
- In-Sprint-Aktivitäten: Der Fokus und die Verantwortlichkeiten mussten bei allen Qualitätsaktivitäten ins Team verschoben werden. Ermöglicht hat dies der Ausbau von Testautomatisierung und Coaching des QM-Mindsets. Durch das Bekenntnis der Teams, die Definition of Done und Definition of Ready zu respektieren, konnte nachhaltige Qualität in die Software einfließen.
- Cross-Sprint-Aktivitäten: Testaktivitäten, die aus Ressourcen-, zeitlichen oder Komplexitätsgründen nicht im Team abgearbeitet werden konnten, wurden in ein Cross-Sprint-Team ausgelagert. Dazu wurde ein Abstimmungsvorgehen etabliert, um den Wissensaustausch zwischen den Teams so effizient wie möglich zu gestalten. E2E-Geschäftsprozesstests, Lasttests, Performanztests und projektübergreifende Schnittstellentests wurden in dem eigenständigen Testteam abgedeckt.
- Verschiebung des Testfokus: Von ehemals 23.000 manuellen Tests erfolgte ein Programmumbau auf 4.500 vollständig automatisierte und 450 manuelle UI-Tests. Der Fokus lag dabei auf der Reduzierung der UI- und dem Ausbau der Unit-Tests. Aktuell werden mit jedem Buildprozess ca. 40.000 Unit-Tests durchgeführt.
Alle genannten Beispiele wirken sich positiv auf den Testprozess und die Testaktiväten aus. Dies reduzierte den Managementaufwand und stärkte die Selbstorganisation signifikant. Weniger Arbeitspakete und mehr wirklich gelebte Qualität in den Teams sowie mehr Geschwindigkeit durch intrinsischen Antrieb in Richtung Automatisierung und damit eine immer weitere Annäherung in Richtung DevOps und Continuous Delivery zahlen am Ende auf unser aller Ziel – Kundenzentrierung – ein.
Es ist besonders wichtig, den QM-Ansatz so zu wählen, dass der Shift-left-Ansatz so weit wie möglich umgesetzt wird, um möglichst eine enge Zusammenarbeit zwischen Testern, Entwicklern und Business-Analysten zu fördern. Mit dem Qualitätsfilter (siehe Abbildung 2) ist auch die Testautomatisierungsstrategie, die wir im Artikel über Säule 3 [KarlLiedl19] bereits ausführlich beschrieben haben, eng verknüpft. Der strategische Ansatz für QM-Vorgehen und die Teststrategie werden aber im Rahmen der Überlegungen in Säule 2 bereits festgelegt. Dies ist relevant, um etwaige Doppelaufwände oder blinde Flecken im QM-Vorgehen zu vermeiden und damit auch ein optimales Kosten-Nutzenverhältnis zu erreichen.
Abb. 2: Der Qualitätsfilter – Definition der strukturellen Grundlagen der DevSecOps-Pipeline
Hierfür muss im spezifischen Kundenkontext die perfekte Mischung zwischen Agilität, Skalierung und Effizienz erreicht werden, um eine Balance zwischen standardisiertem Prozessdenken und Selbstorganisation in den Teams entstehen zu lassen. Je größer und komplexer die Organisation und das zu entwickelnde Produkt sind, desto mehr Absprache ist nötig. Hierfür hat sich beispielsweise die Etablierung von Leitplanken, innerhalb derer sich die Teams bewegen dürfen, beispielsweise in Form eines Architectural Runways, wie sie im SAFe®-Framework empfohlen wird, bewährt [KarlKum20].
In unserer heutigen, sich ständig verändernden Welt ist ein klares Kommunikationskonzept essenziell. Insbesondere eine einheitliche Sprache ist für die Sinnerfüllung des einzelnen Mitarbeiters, das Teambuilding, die Vermeidung von Missverständnissen und einen möglichst effizienten und zielgerichteten, langfristigen Erfolg entscheidend. Missverständnisse sind oft in Projekten mit Qualitätsproblemen zu finden und beginnen bei scheinbaren Kleinigkeiten wie der Definition der Teststufen. Oft sind innerhalb der Teststufe unterschiedliche Begrifflichkeiten zu finden, die ein unterschiedliches Verständnis bezüglich der Aufgaben und Verantwortlichkeiten mit sich bringen. So werden häufig die Begriffe Unit-, Entwickler- und Komponententest parallel verwendet, wobei jede Interessensgruppe damit unterschiedliche Inhalte und Ziele verbindet.
Dieses Phänomen ist meist über alle Ebenen verbreitet und führt am Ende zu einer Softwarelösung, die von den gesetzten Erwartungen abweicht. Das Beispiel verdeutlicht, dass Qualitätsmanagement bereits weit vor dem Softwaretesten beginnt und auch darüber hinausreicht. Aus einem einheitlichen Verständnis von Aufgaben und Verantwortlichkeiten lässt sich ein einheitliches Verständnis von Rollen und Teamstrukturen ableiten. Dies wurde im Artikel zu Säule 1 beschrieben [KarlLiedl20].
Fazit
Mit dem House of agile Testing und der Ausrichtung der QM-Strategie und des Testprozesses in Säule 2 ist es möglich, die Qualitätsaspekte mit den Skalierungsframeworks zu vereinen. Damit gelingt es (uns), den Weg aus dem Dschungel agiler Frameworks einerseits und organisations- beziehungsweise kundenspezifischen Qualitätsanforderungen andererseits zu finden. Der Lichtblick am Horizont hilft der gesamten IT-Organisation, den wichtigen Aspekt der kundenzentrierten Softwareentwicklung umzusetzen und so die Kundenzufriedenheit zu steigern.
Alle Maßnahmen und Aktivitäten innerhalb der Säule 2 sind darauf ausgelegt, eine optimale Passung zwischen agilem Framework einerseits und effizientem Testprozess anderseits sicherzustellen. Dabei sind die verschiedenen Testaktivitäten so im Softwareentwicklungsprozess zu verankern, dass die richtigen Artefakte zum idealen und frühestmöglichen Zeitpunkt im Testprozess getestet werden. Der Einsatz von geeigneten Methoden und Tools zum richtigen Zeitpunkt führte bei unseren Projekten, wie im Praxisbeispiel beschrieben, Schritt für Schritt zu Effizienzsteigerungen unter Einbeziehung des Fachwissens aller Experten in den Teams.
Weitere Informationen
[KarlKum20] T. Karl, M. Kumlehn, Lean Agile Quality Management in einer SAFe® SAP-Umgebung – Die Bedeutung der Architectural Runway aus Managementsicht, in: German Testing Magazin, 2/2020, siehe:
https://webreader.objektspektrum.de/de/profiles/7d30f3fc5f62-objektspektrum/editions/german-testing-magazin-02-2020/pages
[KarlLiedl18] N. Liedl, T. Karl, Agiles Quality Engineering – Qualitätssicherung im Kontext von großen agilen Softwareentwicklungsprojekten, in: German Testing Magazin, 2/2018, siehe:
https://webreader.objektspektrum.de/de/profiles/7d30f3fc5f62-objektspektrum/editions/german-testing-magazin-02-2018/pages
[KarlLiedl19] T. Karl, N. Liedl, House of Agile Testing – Von der Testpyramide zur Testtanne als Methode zur Toolintegration, in: German Testing Magazin, 1/2019, siehe:
https://webreader.objektspektrum.de/de/profiles/7d30f3fc5f62-objektspektrum/editions/german-testing-magazin-01-2019/pages
[KarlLiedl20] T. Karl, N. Liedl, House of Agile Testing, Säule 1: Rollen – Ein Arbeitsorganisatorischer Ansatz in der VUKA-Welt, in: German Testing Magazin, 2/2020, siehe:
https://webreader.objektspektrum.de/de/profiles/7d30f3fc5f62-objektspektrum/editions/german-testing-magazin-02-2020/pages
