Stellen Sie sich vor, Sie wollen sich in einer App ein U-Bahn-Ticket kaufen. Beim ersten Versuch stürzt die App ab. Beim zweiten Versuch stellen Sie fest, dass die aktuellen Tarifänderungen noch nicht in der App reflektiert werden. In der Zwischenzeit ist Ihre Bahn abgefahren. Natürlich ist das ärgerlich und als Endnutzer erwarten wir die letzten Sicherheits- und Funktionsupdates zeitnah auf unseren Applikationen.
Wir brauchen also die schnelle Reaktion auf Änderungen, die man von einer agilen Arbeitsweise erwarten kann. Qualität ist hierbei allerdings absolut kein Nebenprodukt, sondern ein essenzieller Treiber. Der Bereich „Test Fundament“ im erfolgreich in Dutzenden Unternehmen angewendeten „House of Agile Testing“ (HoaT) geht darauf genauer ein.
Während aktuelle in der Softwareentwicklung etablierte Frameworks wie Scrum, SAFe® und Kanban sich vor allem auf die Veränderungen in Bezug auf die Zusammenarbeit, den Arbeitsprozess und die Mentalität der Menschen innerhalb der Organisation beziehen, werden die Aspekte der Qualitätssicherung meist nur implizit ausgeführt. Bei einer agilen Transformation oder der Skalierung von Agilität muss auch das Testing einige Veränderungen beachten und sich ganzheitlich mitentwickeln. Diese Weiterentwicklung im Test muss Schritt halten mit der Weiterentwicklung in allen anderen Bereichen, da eine erfolgreiche agile Transformation einer holistischen Veränderung bedarf, für welche das HoaT den Rahmen setzt. Im ersten Teil dieses Artikels wird das „House of Agile Testing“ in seiner Gesamtheit vorgestellt. Anschließend werden die folgenden Aspekte des „Test Fundaments“ genauer beleuchtet:
- Ziele des (Software)tests,
- Teststufen,
- methodische Grundlagen.
Dabei wird insbesondere darauf eingegangen, welche Unterschiede in der agilen Welt gegenüber der klassischen Entwicklung zu erwarten sind.
Das „House of Agile Testing” als Leitlinie
Eine Orientierung, wie sich Qualitätssicherung erfolgreich ins Agile führen lässt, bietet das von Nico Liedl und Thomas Karl entwickelte „House of Agile Testing“ ([KaLi18], Abb. 1]. Dieses umfasst fünf Bereiche, die jeweils für sich und in Bezug aufeinander betrachtet werden sollten, um eine erfolgreiche Transformation ins Agile Testing zu gewährleisten. Außerdem kann es herangezogen werden, um zu evaluieren, wo Ihr Unternehmen sich in der Transformation befindet.
Abb. 1: House of Agile Testing [KaLi20]
Die Basis bildet hierbei das „Test Fundament“. Hierbei geht es darum, die Qualitätsstandards, die man aus der klassischen Softwareentwicklung kennt, nicht gänzlich zu verwerfen, sondern im Gegenteil weiter zu berücksichtigen und auf die Agile Arbeitsweise und Mentalität hin zu adaptieren. Auf diesen Aspekt wird der Artikel im Folgenden genauer eingehen.
Steht das Fundament, können die drei Säulen „Rollen“, „Ansatz“ sowie „Tools und unterstützende Maßnahmen“ darauf aufgebaut werden. Sind die Säulen bis zu einem gewissen, gleichmäßigen Reifegrad aufgezogen, kann darauf das Dach gebaut werden. Das Dach umfasst dann „Lean Quality Engineering Methoden“, worunter komplexere Methoden und Techniken verstanden werden.
Ziele des Testings im Agilen
Wollen wir mit Testing immer noch die Software- und Prozess-Qualität steigern? Und damit Vertrauen in die Qualität schaffen? Geht es uns immer noch darum, das Fehlerrisiko zu senken oder sogar vorzubeugen? Wollen wir nach wie vor vertragliche oder gesetzliche Industrienormen erfüllen? Ja, auf jeden Fall.
Die Ziele bleiben im Grunde genommen die gleichen. Es sollte sich weiterhin an Softwarequalitätsmerkmalen wie in Abbildung 2 aufgelistet sowie nationale und internationale Standards orientiert werden. Je nach Branche und Produkt besteht ohnehin die Pflicht dazu, völlig egal, nach welcher Methode Software entwickelt wird.
Abb. 2: Softwarequalitätsmerkmale nach DIN 66272 bzw. ISO/IEC 9126
Was sich ändert, ist zum einen die Einstellung der an der Qualität beteiligten Akteure. Nicht eine definierte Qualitätsabteilung möchte diese Ziele mit aller Kraft verfolgen und durchsetzen, sondern das gesamte Entwicklungsteam zieht hier an einem Strang (Collective Ownership for Quality).
Außerdem spielt die Qualität von Anfang an, begonnen mit der Anforderungsanalyse bis hin zum Deployment, eine essenzielle Rolle. Das Ziel hierbei ist, Fehler so früh wie möglich zu erkennen und zu vermeiden. Das ist auch ökonomisch sinnvoll, da die relativen Kosten einen Fehler zu fixen, eng damit korrelieren, wie früh der Fehler gefunden wird. Wird ein Fehler schon in den Akzeptanzkriterien erkannt und korrigiert, ist das wenig Aufwand. Findet man einen Fehler erst kurz vor dem Deployment, werden im Best-case-Szenario alle Schritte zurückverfolgt, ggf. bis hin zur Anforderung selbst. Wird diese korrigiert, folgt der ganze „Rattenschwanz“ inklusive Design, Entwicklung, Re-Test. Je nach Komplexität des Systems und Anzahl der Testphasen kann das einen enormen Unterschied machen (vgl. ISTQB CTFL Syllabus [ISTQB-a]). Wegen des hohen Aufwandes kommt es auch oft vor, dass Defekte nur provisorisch gefixt werden und dadurch zu einem späteren Zeitpunkt zu noch größeren Problemen führen.
Brauchen wir noch Teststufen?
Auch hier ist die Antwort ja. Die Teststufen wie Komponententest, Integrationstest, Systemtest (inklusive funktionaler und nicht-funktionaler Tests) und Akzeptanztest (vgl. ISTQB CTFL Syllabus) bleiben relevant, nur finden sie in viel kürzeren Zyklen statt und manifestieren sich nicht mehr in der Organisationsstruktur eines Unternehmens durch getrennte Abteilungen oder Teams. Das ist besonders wichtig, damit die Entwickler früh Feedback bekommen und Fehler beheben können, bevor diese größere Auswirkungen haben.
Das Prinzip des frühen Feedbacks ist in der agilen Entwicklung verankert (vgl. ISTQB CTAL-AT Syllabus [ISTQB-b]). Frühes Feedback dient also nicht nur der Schnelligkeit, sondern führt auch zu besserer Qualität. Andersrum ermöglicht höhere Qualität auch schnelleres Feedback und beides hilft auch noch dabei, Kosten zu sparen, wie im vorangegangenen Absatz erläutert.
Häufig wird der Name der Teststufen angepasst, um eine Unterscheidung zu den vorherigen Teststufen aus der Wasserfallwelt deutlich zu machen. Dabei wird zum Beispiel direkt Bezug auf die Artefakte oder Programmlevel genommen. Typisch sind daher Namen wie Storytest, Featuretest, Solutiontest usw. Auch wenn der Name selbst eher sekundär ist, ist es besonders wichtig sicherzustellen, dass alle das gleiche Verständnis der Teststufen haben. Somit wird vermieden, dass sich unterschiedliche Bezeichnungen für die gleichen Teststufen etablieren, die langfristig zu Inkonsistenz, Verwirrung und teils unnötiger Doppelarbeit führen könnten. Die Teststufen sind also ein Beispiel für eine „gemeinsame Sprache“, auf die in der Säule 2 „Ansatz“ genauer eingegangen wird.
Welche Testtechnik passt am besten?
Jahrelang wurde die Auswahl von Testtechniken von Faktoren bestimmt wie
- Komplexität des zu testenden Systems
- Regulatorische Standards
- Verfügbare Dokumentation
- Risikostufen
- Vorkenntnisse des Testers
- Zeit und Budget und
- Softwareentwicklungslebenszyklusmodell (vgl. ISTQB CTFL Syllabus).
Der Wandel zur agilen Entwicklung stellt davon einiges auf den Kopf. Darauf reagieren auch internationale Zertifizierungsstellen wie ISTQB und haben zum Teil existierende Trainings und Dokumentationen erweitert oder auch neue, ergänzende Trainings entwickelt.
Besonders betroffen sind der Zeitfaktor sowie der Grad und die Art der Dokumentation. Die kürzeren Entwicklungszyklen machen zeitaufwendige Testtechniken, welche manuell ausgeführt werden, schwierig und schränken die Auswahl solcher Vorgehensweisen ein.
Von den bekannten Testfallentwurfsmethoden lässt sich besonders gut die anwendungsfallbasierte Testtechnik anwenden. User-Storys können herangezogen werden, um mit dem gesamten Team die Testfälle direkt von den Akzeptanzkriterien abzuleiten. Wichtig ist hierbei, sich nicht stupide auf diese zu beschränken, sondern den systemischen Blick eines Testers beizubehalten. Falls weitere Testfälle sinnvoll sind, sollte dies auf jeden Fall im Team besprochen und die Akzeptanzkriterien entsprechend erweitert werden. Hier können auch bekannte Methoden wie Kombinatorik zum Einsatz kommen, um sowohl den Aufwand als auch das Risiko geringer zu halten. Damit ein teamübergreifend gleichmäßiges Qualitätsniveau gewährleistet werden kann, empfiehlt es sich, einige Kriterien in die Definition of Ready und Definition of Done aufzunehmen. Auch hierbei ist die Tester-Erfahrung unabdinglich.
Außerdem ist es aus verschiedenen Gründen zu empfehlen, die Testfälle und -ergebnisse zwar effizienter, aber dennoch nachvollziehbar zu dokumentieren:
- Sie können für Regressionstests oder spätere progressive Tests weiterverwendet werden.
- Viele Unternehmen benötigen die Testnachweise zum Einhalten von rechtlichen Vorschriften.
- Die Testfälle können beim Ausfall des Testers von einem anderen Teammitglied durchgeführt werden, manuell oder – noch besser – automatisiert.
Um eine transparente Zusammenarbeit zu gewährleisten, sollte die Dokumentation in einem Tool erfolgen, auf das alle relevanten Stakeholder Zugriff haben. Auf keinen Fall sollte mit einzelnen Dateien, die in E-Mail-Ketten untergehen oder lokal abgespeichert werden, gearbeitet werden. Testmanagement- und Automationtools sind hier extrem hilfreich, indem sie zum Beispiel Screenshots während der Testdurchführung machen und Details mitaufzeichnen. So können Compliance-Anforderungen ohne manuelle Zusatzaufwände erfüllt werden. Darüber hinaus bilden derartige Dokumentationen von E2E-Prozessen oftmals eine hervorragende Ausgangsbasis für die Erstellung von Trainingsunterlagen oder Nutzer-Handouts.
Auch wenn das agile Wertepaar „working software over comprehensive documentation“ (funktionierende Software über umfangreiche Dokumentation) häufig in Unternehmen im agilen Wandel zu Fehlinterpretationen führt, spielen Dokumentationen besonders für die Qualitätssicherung nach wie vor eine große Rolle. Hierzu helfen die Testspezialisten dem Team, den Mehrwert von Dokumentation besser zu verstehen und auch zu nutzen.
Wie verändert sich das Testmanagement?
Das typische Testmanagement, das unter anderem die Aspekte der Testplanung und -organisation, Reporting, Risiko- und Defektmanagement umfasst, wird weiterhin benötigt. Allerdings werden die Aktivitäten nicht mehr von einer einzelnen Person ausgeführt, sondern durch das gesamte Team getrieben. Wegweisend sind hierbei die Business Values, die den einzelnen Features zugewiesen werden. Bei SAFe® werden diese zum Beispiel im PI Planning1 durch die Business Owner vergeben und helfen den Teams, entsprechend zu priorisieren.
Auch das Testreporting ist weiterhin relevant, damit die Qualität und der Fortschritt transparent sind und lenkbar bleiben. Die Qualität zwischen den Teams bleibt vergleichbar und es kann kontinuierlich an der Verbesserung der Qualität gearbeitet werden. Dabei können bekannte Metriken angewendet werden. In der Regel müssen die bestehenden Reportings allerdings auf die neue agile Arbeitsweise angepasst werden.
Ansätze wie das risikobasierte Testing finden weiterhin Beachtung. Nach wie vor gilt der Grundsatz: „Man kann nicht alles testen.“ Bei komplexeren Funktionalitäten ist es durchaus sinnvoll, die Auswirkung und Wahrscheinlichkeit, dass ein Fehler eintreten könnte, zu berücksichtigen, um Testszenarien zu priorisieren. Dafür ist es wichtig, mögliche Risiken schon in den Refinements der Epics und User-Storys zu betrachten. Dadurch fällt rechtzeitig auf, ob die geplante Umsetzung der Anforderungen überhaupt testbar ist und insbesondere, ob die identifizierten Risikobereiche abgedeckt sind. Falls notwendig kann entsprechend gegengesteuert werden. Testfälle, welche wiederverwendet werden sollen, zum Beispiel für Regressionstests, müssen aus Effizienzgründen automatisiert werden. Bei Testszenarien, die vermutlich nur einmalig ausgeführt werden, lohnt sich der Automatisierungsaufwand i. d. R. meist nicht. Hier bietet sich manuelles, exploratives Testen zumindest für UI-Tests an. Ausnahmen von der Regel gibt es immer, beispielsweise, wenn generell ein Test-driven-development-Ansatz verwendet wird.
Damit das Defektmanagement auch teamübergreifend funktionieren kann, ist es essenziell, dass die Teams verstehen, welche Abhängigkeiten zwischen den Systemen und Features bestehen. Auch die Ansprechpartner sollten klar und transparent für alle Teams dokumentiert sein.
1) PI Planning = Das PI Planning ist eine Zeremonie aus dem SAFe® Framework, wobei alle Teams und alle sonstigen am SAFe-Programm Beteiligten zusammen kommen, um den Entwicklungs-Scope für ein festgelegtes Intervall zu planen. Dabei wird ein besonderes Augenmerk auf Abhängigkeiten und Risiken gelegt.
Können wir das Testing weiterhin durch Tools stützen?
Der Einsatz von Tools für das Testmanagement und die automatisierte Durchführung von Tests ist auf jeden Fall empfehlenswert und muss i. d. R. im agilen Kontext sogar noch deutlich erhöht werden.
Häufig ist mit dem Wandel ins Agile auch ein Umzug in ein neues Testmanagement-Tool inbegriffen. In vielen Fällen sucht das Unternehmen ein Tool für das agile Projektmanagement aus und die Qualitätsverantwortlichen integrieren die Testdokumentation. Eine Einbeziehung von QM-Experten in den Auswahlprozess von Beginn an wird dringend empfohlen.
In jedem Fall gilt es zu überprüfen, ob das vorhandene Tool zur agilen Arbeitsweise passt und eine gute Rückverfolgbarkeit garantiert: Ist es mit anderen Tools, die die Entwicklung und Defekte tracken, integriert? Kann man sinnvoll Metriken tracken und aus dem Tool exportieren? Bildet das Tool den notwendigen Workflow korrekt ab?
Auch für die Testautomatisierung sollte sichergestellt werden, dass das Tool-Set-up mit anderen verwendeten Tools integriert werden kann. Die Zusammenstellung der richtigen Tools kann ziemlich komplex sein, da häufig auch Methoden für Dev(Sec)Ops berücksichtigt werden müssen. Die Aufgabe der Integration und Orchestrierung von Tools darf keinesfalls unterschätzt werden. Die Testautomatisierung im agilen Set-up steht in der Säule 3 „Tools und unterstützende Maßnahmen“ im Fokus, in dem die technischen und prozessualen Fragen der Toolauswahl thematisiert werden [Li-Ka20].
Fazit
Zusammenfassend lässt sich sagen, es empfiehlt sich, das Rad nicht immer wieder neu zu erfinden. Die Standards, Techniken und Methoden, die wir im traditionellen Test kennengelernt haben, finden sich auch in der agilen Arbeitsweise in der ein oder anderen Form wieder. Vielmehr als das sind sie die essenzielle Basis, auf der die agile Qualitätssicherung aufgebaut wird. Wichtig sind hier einerseits das Einbeziehen des gesamten Teams in Test und Qualitätssicherungsmaßnahmen, ein klares Commitment in Richtung Automatisierung und ein stetiger Antrieb zur Verbesserung im Rahmen von kontinuierlicher Verbesserung. So kann das aus der „alten Welt“ gewohnte Qualitätsniveau sorgenfrei in die neue Welt übertragen werden und für ein zukunftsweisendes effizienteres Qualitätsmanagement adaptiert werden, um die Qualität noch weiter zu verbessern.
Weitere Informationen
[KaLi18] Th. Karl, N. Liedl, Qualitätssicherung im Kontext großer Agiler Softwareentwicklungsprojekte, in: German Testing Magazin, 2/2018, s. a.
https://www.accenture.com/_acnmedia/PDF-142/Accenture-German-Testing-Magazin.pdf, S. 32 ff
[KaLi20] Th. Karl, N. Liedl, House of Agile Testing – Säule 1: Rollen, in: German Testing Magazin, 2/2020
[LiKa20] N. Liedl, Th. Karl, Testautomatisierung 4.0 mithilfe des House of Agile Testing, in: JavaSPEKTRUM, 3/2020
[ISTQB-a] ISTQB CTFL Syllabus, siehe:
https://www.istqb.org/downloads/send/2-foundation-level-documents/281-istqb-ctflsyllabus-2018-v3-1.html
[ISTQB-b] ISTQB CTAL-AT Syllabus, siehe:
https://www.istqb.org/downloads/send/5-foundation-level-agile-tester/41-agile-testerextension-syllabus.html
