Abb. 1: House of agile Testing
Um in einem wie oben beschriebenen Umfeld grundsätzliche Leitlinien zu etablieren, haben wir das in Abbildung 1 dargestellte „House of agile Testing“ (im Folgenden: HoaT) entwickelt. Es setzt sich aus fünf Teilbereichen zusammen. Die Basis bilden die „Test Basics”. Ohne diese methodischen Ansätze und die damit verbundenen Arbeitsweisen können in der Qualitätssicherung nicht die gewünschten Ergebnisse erzielt werden.
Darauf bauen die drei Säulen „Menschen und Rollen“, „Ansatz“ und „Tools“ auf. Wenn diese drei Säulen aufgebaut sind und eine gewisse Reife aufweisen, wird das Haus mit „Fortgeschrittene agile Techniken“ vervollständigt, um auch komplexere Methoden und Techniken einzuführen.
Zuletzt sind wir in unserem Artikel „Qualitätssicherung im Kontext von großen agilen Softwareentwicklungsprojekten“ [Kar18] und in unseren Vorträgen auf dem German Testing Day 2018 und der OOP 2019 in München auf das HoaT eingegangen. Dabei haben wir dieses Konzept anhand eines konkreten Praxisbeispiels vorgestellt und die Anwendung erläutert.
Die Säulen des HoaT
In der Säule „Menschen und Rollen“ gilt es, Fragen bezüglich der künftig notwendigen Rollen zu beantworten. Die Ausgestaltung hängt von der gewählten agilen Softwareentwicklungs- beziehungsweise Skalierungsmethode ab und auch davon, ob Spezialrollen für den Test benötigt werden. Direkt damit verbunden ist die Frage nach dem notwendigen technischen Wissen und Verständnis in den einzelnen agilen Rollen. Insbesondere ist zu klären, in welchem Umfang und welcher Tiefe technisches Wissen auf- und ausgebaut werden muss. Erst nach dieser Klärung werden die organisatorischen Strukturen weiterentwickelt und letztlich die neuen oder angepassten Rollen in der Organisation etabliert.
Die Säule „Ansatz“ beinhaltet die Frage nach dem Testansatz, der sich aus dem gewählten Liefervorgehen ableitet. Insbesondere bei der Einführung von Agilität in Großprojekten, die Teil von komplexen IT-Systemlandschaften sind, wird zu Beginn einer agilen Transformaion 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 ist zu klären, welche Inhalte innerhalb der Sprints getestet werden können und welche Teile der Software nachgelagert geprüft werden müssen.
Der Schwerpunkt unseres Artikels liegt auf der Säule „Tools“. Diese beinhaltet die technischen und prozessualen Fragen der Toolauswahl. Es ist zu klären, welche Testautomatisierungstools am besten den gewählten Entwicklungsansatz unterstützen und ob bestehende eigenentwickelte Testautomatisierungstools weiterverwendet werden können. Gleichzeitig muss betrachtet werden, welche und wie viele Testumgebungen benötigt und wie diese mit Testdaten versorgt werden. Für ein effizientes Liefer- und Testvorgehen ist dann insbesondere die Einbettung der einzelnen Tools und Umgebungen in eine Endto-End-Tool-Pipeline zu beachten.
Von der Pyramide zum Tannenbaum
Die Kernfrage verbleibt jedoch: Wie ist es möglich, alle Testaktivitäten aus der „alten Welt“ in nur einem Sprint für das „potentially shippable product“ durchzuführen?
Viele Testexperten kennen sowohl das Problem als auch die aus der Literatur bekannte Testautomatisierungspyramide [Coh09] von Mike Cohn und die damit verbundene Forderung nach vollumfänglicher Testautomatisierung. Die zentrale Herausforderung ist jedoch deren Umsetzung. Das Prinzip des „shift left“ gibt klare Strukturen dafür vor, wie Testaktivitäten sinnvoll aneinandergereiht werden, um mit einer vorgegebenen Sprintlänge alle nötigen Testaktivitäten umsetzen zu können. Das Ziel ist dabei, die Testaktivitäten zum frühestmöglichen Zeitpunkt durchzuführen. Umsetzbar ist das nur durch ein massives Engagement in der Testautomatisierung.
Betrachtet man die Realität der aktuellen Softwareentwicklungsprojekte, so scheint das Konzept der Testpyramide mittlerweile zu kurz gegriffen zu sein. Aus unserer Sicht, muss deshalb eine konzeptionelle Erweiterung des Ansatzes hin zu einem Testtannenbaum, wie in Abbildung 2 dargestellt, erfolgen. Dies bedeutet, dass vom ersten Schritt im Anforderungsprozess bis zum Go-Live der Software mehrere aufeinander aufbauende Testpyramiden durchlaufen werden. Jedes am Entwicklungsprozess beteiligte Unternehmen oder Projektteam durchläuft dabei eine eigene Testpyramide. Diese Denkweise hat sich bereits in mehreren Praxisprojekten der Autoren bewährt und zu einer Optimierung des Verhältnisses der Testaufwände zu gelieferter Qualität geführt.
Was verbirgt sich genau hinter dem Testtannenbaum? Das Konzept basiert auf der Erkenntnis, dass bei der Softwareentwicklung immer häufiger auf bestehende Komponenten wie Frameworks, Microservices, kommerzielle und Open-Source-Standardsoftware oder einen generativen Ansatz zurückgegriffen wird. Diese Komponenten haben für sich bereits Qualitätssicherungsmaßnahmen, gegebenenfalls sogar in Form einer Testpyramide, durchlaufen. Ein Komponententest (vgl. ISTQB) in der finalen Software stellt somit in vielen Fällen nicht die erste, sondern bereits die dritte oder vierte Teststufe des Softwareartefakts dar.
Die Herausforderung ist, die unterschiedlichen Testpyramiden zu identifizieren und so zu verknüpfen, dass am Ende ein gut proportionierter, effizienter Testtannenbaum entsteht. In einem solchen Tannenbaum werden Artefakte möglichst früh und nur so oft wie nötig getestet. So wird ein risikobasierter Testansatz eingeführt, in dem Fehler früh gefunden werden können und in jedem Abschnitt des Testtannenbaums der Fokus und das Budget auf die wichtigen QS-Maßnahmen konzentriert werden.
Abb. 2: Testtannenbaum nach Karl und Liedl
Praxisbericht
Konkret lässt sich das am Beispiel eines Projektes mit modellgetriebenem Softwareentwicklungsprozess darstellen. Die Entwicklung des Frameworks für die Modellierung und Generierung erfolgt „in house“ (als Projekt im Projekt) und erlaubt somit eine abgestimmte Qualitätssicherung mit sinnvoll und effektiv aufeinander abgestimmten Testaktivitäten. So entsteht unter Berücksichtigung einer Risikoabwägung eine durchgängige Kette von effektiven Testaktivitäten – ein Testtannenbaum.
Wenn beispielsweise der Code für die Darstellung einer Tabelle im Framework vollständig automatisch generiert wird und die Generierung getestet wurde, müssen das Layout und die Anordnung in den Teststufen „in der Spitze des Baums“ mit signifikant reduziertem Umfang oder im besten Fall gar nicht mehr abgesichert werden. Insofern skaliert die Einsparung dieser abgestimmten QS-Maßnahme aus der unteren Testpyramide in jedes einzelne Vorkommen einer Tabelle. Die „Wolke“ über dem Testtannenbaum bildet die manuellen Schritte der Qualitätssicherung ab, in dieser Phase können die Bereiche frei abgetestet werden, um sicherzustellen, dass Fehler, die in den Vorstufen gegebenenfalls nicht erkannt wurden, doch noch entdeckt werden.
Beispiele, in denen man intuitiv auf genau diesen Mechanismus aufbaut, sind beispielsweise eigenentwickelte Frameworks (DSLs, MDD, …), Kaufsoftware wie Warenwirtschaftssysteme, SAP-Implementationen oder CMS-Systeme die erweitertet/customised werden. Der Test und insbesondere die Testautomatisierung starten abgestimmt auf die zugelieferte Grundqualität. Die Orchestrierung der eingesetzten Tools stellt den nächsten wichtigen Schritt auf dem Weg zur Testtanne dar.
Qualität am Fließband
Der Aufbau einer End-to-End-Qualitätspipeline (von der ersten bis zur letzen Qualitätssicherungsaufgabe) in Form des oben skizzierten Testtannenbaums wird dabei eine der erfolgskritischen Kernaufgaben darstellen. Insbesondere im oftmals zitierten „skalierten agilen Umfeld“, in welchem die Erwartungshaltung „Release on Demand“ als Standard angesehen wird, bietet der Testtannenbaum die konzeptionelle Leitlinie zum Aufbau einer effizienten End-to-End-Qualitätspipeline. Mithilfe dieses Modells lässt sich das risikoorientierte Testen in eine nächste Evolutionsstufe bringen und in Richtung einer agilen DevOps-Welt weiterentwickeln.
In diesem Umfeld wird sich die Rolle des „fachlichen Testers“ dramatisch ändern, da in Zukunft die Aufgaben um einiges weitreichender und vor allem aus technischer Sicht komplexer werden. Dies bedeutet nicht zwangsläufig, dass der einzelne Tester mehr oder kognitiv anspruchsvollere Aufgaben hat, sondern lediglich, dass er andere Aufgaben bekommt. Vielmehr ist damit gemeint, dass der Softwareentwicklungs- und Testprozess komplexer wird und der Tester an anderen Stellen im Prozess neue Aufgaben hat.
Referenzen
[Coh09]
M. Cohn, Succeeding with Agile, Software Development Using Scrum, Pearson Education, 2009
[Kar18]
Th. Karl, N. Liedl, Qualitätssicherung im Kontext von Großen agilen Softwareentwicklungsprojekten, in: German Testing Magazin, 2/2018, siehe auch:
https://www.accenture.com/t00010101T000000Z__w__/de-de/_acnmedia/PDF-94/Accenture-Qualitatssicherung.pdf#zoom=50
