Der erste Teil des Artikels befasst sich mit der Teststrategie. Hier wird erläutert, wie das Shift-left-Verfahren beim Testing gezielt in vier Teststufen eingesetzt werden kann. Im zweiten Teil wird kurz über die Erfahrung und die Ergebnisse dieser Teststrategie bei dem Bankkunden berichtet.
Um den Test in diesem agilen Modell kurz vorzustellen, vorab ein paar FAQs:
- Was ist Shift-left Testing? Dies ist ein Vorgehen, welches verschiedene Testansätze in früheren Stadien eines Softwarezyklus nutzt, um die Testabdeckung zu erhöhen und die Qualität der Tests zu verbessern. Dauerhaft führt dies zu einer Reduktion der Kosten, da früh identifizierte Testabweichungen weniger Aufwand für die Entwicklung sind als in einer späteren Phase des Softwarezyklus.
- Welche Fähigkeiten braucht ein Tester? Er muss im Stande sein, fachliche und auch technische Anforderungen in Testfallspezifikationen (hier: Workflows und Testszenarien) zu übersetzen. Im besten Fall ist der Tester auch Testautomatisierer, um den ständig wiederholten Bedarf an Regressions- sowie Last- und Performanztests zu decken.
- Welche Voraussetzungen müssen für erfolgreiches Shift-left Testing in vier Teststufen geschaffen sein? Ein gut strukturiertes Testumgebungsmanagement spielt hierbei eine zentrale Rolle. Vier Teststufen bedeuten nämlich auch, dass für jede Stufe eine eigene Testumgebung mit entsprechenden Testdaten bereitstehen muss. Ein geeignetes Testdatenmanagement, das die unterschiedlichen Testdaten, je nach Bedarf und Nutzungsgenehmigung, auf den jeweiligen Umgebungen bereitstellt, ist ebenfalls wichtiger Bestandteil der Teststrategie. Aufgrund der Datenschutzgrundverordnung (DSGVO), welche seit Mai 2018 anzuwenden ist, gewinnt dieser Bereich zudem immer mehr an Bedeutung. Verfahren zur Pseudonymisierung, Anonymisierung oder Anlage von synthetischen Testdaten sind die möglichen Lösungen, um sich von den produktionsgleichen Daten zu distanzieren.
Testen in vier Stufen
Vorbereitung durch Test-Driven Requirement Analysis
Das Vier-Stufen-Modell im Shift-left Testing (siehe Abbildung 1) beginnt schon vor der ersten Stufe.
In Vorbereitung auf die Entwicklung beginnt die Arbeit für das Testteam schon in der Anforderungsanalyse: Test-Driven Requirement Analysis. Bevor die fachlichen Anforderungen und Features in User-Storys runtergebrochen werden, werden vom Testteam Main-Workflows und alternative Workflows sowie dazugehörige Testdatenkonstellationen ausgearbeitet. Anhand dieser Vorbereitung werden dann die User-Storys und Akzeptanzkriterien geklärt und definiert.
Abb. 1: Vier-Stufen-Modell
Stufe 1 – Entwicklertests, doppelte Code-Reviews und statische Codeanalyse
Über JIRA erhalten Entwickler bei jedem Sprintbeginn die User-Storys. Auf JIRA wird der Entwicklungsprozess in den einzelnen Entwicklungsstufen dokumentiert. Bei jedem Entwicklungsabschluss einer User-Story erfolgt durch den Entwickler selbst ein Komponententest auf der Entwicklungsumgebung. Die Entwicklung wird dann zudem von einem weiteren Entwickler validiert, sodass hier ein doppelter Code-Review stattfindet. Die Entwicklertests werden während eines Sprints durchgeführt, bevor die User-Storys an das In-Sprint-Testing-Team für einen fachlichen Test übergeben werden.
Stufe 2 – In-Sprint-Tests (fachlich)
Die Übergabe der User-Storys für den Sprint erfolgt gleichzeitig an Entwickler und Tester. Während die Softwareentwicklung startet, beginnt für das Testteam das Wettrennen um die Erstellung der Testfälle für die einzelnen User-Storys. Die Testfallerstellung muss zum Zeitpunkt des Entwicklungsabschlusses ebenfalls abgeschlossen und vor In-Sprint-Testbeginn durch den Product Owner (PO) validiert werden. Nach Entwicklungsabschluss findet auf JIRA die Übergabe der User-Storys an den entsprechenden Tester statt (es gibt einen manuellen Tester pro Scrum-Team). Auch für Tests findet hier auf JIRA eine genaue Dokumentation der Testfallausführung statt, sodass nach Testabschluss eine Entscheidung zur Schließung oder erneuten Entwicklung der User-Story getroffen werden kann oder gar eine Anpassung der Anforderungen erfolgen muss.
Zum Shift-left-Ansatz zählt auch der regelmäßig, während eines Sprints, automatisiert ausgeführte Regressionstest (siehe Abbildung 2). In der zweiten Teststufe wird mit der Testautomatisierung begonnen. Während das manuelle Testteam sich mit den neuen User-Storys des aktuellen Sprints befasst, wenden sich die Testautomatisierer (ebenfalls einer pro Scrum-Team) den regressionsrelevanten User-Storys aus dem vorangegangenen Sprint zu und legen diese Testfälle automatisiert in der TOSCA-Testsuite an. Das Regressionstestportfolio wird auf diesem Weg Sprint für Sprint erweitert, um den letzten Sprintabschluss immer wieder erneut zu validieren.
Abb. 2: Testautomatisierung im Vier-Stufen-Modell
Die Testabdeckung liegt im manuellen Test bei 100 Prozent, das heißt, es werden alle testrelevanten User-Storys und die dazugehörigen Akzeptanzkriterien vertestet. Für die Testautomatisierung liegt das Testabdeckungsziel bei 80 Prozent, hier werden nur die regressionsrelevanten Akzeptanzkriterien in Betracht gezogen.
Stufe 3 – Feedback durch das Fachteam sowie Experten- und Usability-Tests
Um während der Entwicklungssprints den Product Owner über den Entwicklungsfortschritt abzuholen, wird der Sprintreview genutzt. Die Vorstellung der erfolgreich abgeschlossenen User-Storys erfolgt mit dem PO, sodass ein frühes Feedback eingeholt werden kann. Um jedoch Bank-interne Experten und auch zukünftige Anwender abzuholen und eine Akzeptanz der Applikation sicherzustellen, werden diese in Expertentests eingebunden (siehe Abbildung 3).
Abb. 3: Dritte Stufe – Sprintreviews, Experten- und Usability-Tests
Bei einem durch die Product Owner geführten Expertentest werden die bank-internen Experten und zukünftige Anwender vor verschiedene Aufgaben gestellt, die sie in der Anwendung ausführen sollen. Durch diesen geführten sowie zum Teil auch explorativen Test erhält der Experte ein Gefühl für die Anwendung und kann zudem Features für die nächsten Sprints entsprechend der Testergebnisse erweitern oder spezifizieren. Diese Stufe ist zudem eine Vorbereitung auf den User Acceptance Test, da so die Testfallerstellung für Stufe 4 durch das Fachteam mit etwas Vorwissen der Anwendung erfolgt.
Stufe 4 – User Acceptance Test
Bei der Transition von einem Wasserfallmodell zu einer agilen Softwareentwicklung bleibt häufig der User Acceptance Test (UAT) übrig, da dieser bei einer Abnahme von der Revision zur Betrachtung herangezogen wird. Nach Abschluss aller Entwicklungssprints findet daher noch mal ein finaler Test des Releases durch den PO sowie ein Lastund Performanztest statt. Der Last- und Performanztest kommt bei dieser Teststufe ins Spiel, da ab dem Zeitpunkt des UAT die Entwicklungen abgeschlossen sind und die Applikation bereits auf einer höheren und daher auch produktionsnahen Testumgebung deployt worden ist. Die Testergebnisse aus dieser Teststufe sind dann ausschlaggebend für die Entscheidung über die Freigabe der Applikation.
Erfahrungen aus der Praxis
Die Teststrategie über ein Vier-Stufen-Modell entstand in den Anfängen der Entwicklung des ersten Projektreleases bei dem Bankkunden und wurde über die Dauer von 2 Jahren sowie 4 weiteren Releases immer weiter ausgebaut.
Im ersten Release waren die Testautomatisierung der fachlichen Tests sowie ein Last- und Performanztest noch ein Zielbild für die kommenden Releases. Mit der Weiterentwicklung der Applikation durch mehr und komplexere Anforderungen sowie der Erweiterung der bisherigen Anforderungen wuchs auch der Bedarf an Regressionstests, der durch den manuellen Test nicht mehr abzudecken war. Daraufhin wurde die Testautomatisierung des Regressionstests mit der TOSCA-Testsuite erfolgreich in das Projekt integriert. Von der Einführung der Testautomatisierung profitiert auch der PO, da auch während des UAT-Zeitraums Regressionstests automatisiert ausgeführt werden können (siehe Abbildung 4).
Abb. 4: UAT-Aufwand wird verringert
Das dritte und vierte Release war flächendeckend, sodass die Anwendung auf Last- und Performanz geprüft werden musste. Für den Last- und Performanztest wurde Jmeter genutzt, um die technischen Anforderungen zu testen.
Die guten Testergebnisse mit geringeren Defectmeldungen in den Abnahmetests sowie die erfolgreichen Releases spiegeln den Erfolg der Teststrategie wider. Es ist gelungen, mit dem Vier-Stufen-Modell Defects rechtzeitig zu identifizieren, zu beheben und die Qualität des Endprodukts zu sichern.
Ein Messwert, um die Entwicklungsqualität der Applikation und die Testergebnisse zu vergleichen, ist die Defect Density. Diese beschreibt die Anzahl der Defects pro Umgebung oder Teststufe auf 1000 Entwicklerstunden, sodass eine niedrige Defect Density bei 80 bis 100 Prozent Testabdeckung eine gute Entwicklungsleistung darstellt. In diesem Fall wird die Defect Density ab der zweiten Teststufe gemessen. Die Messwerte für den UAT (2,2 – 6,7 Defects/1000 Entwicklerstunden) liegen stets unter dem Durchschnitt von weiteren Accenture-Projekten gemeldeten Werten (< 30 Defects/1000 Entwicklerstunden).
Die Umsetzung der Shift-left-Teststrategie erfolgte stets in enger Zusammenarbeit des Testmanagements mit dem Delivery Manager, Scrum Master und Product Ownern des Projektteams. Das Vier-Stufen-Modell wurde in wiederkehrender Absprache nach Bedarf angepasst oder erweitert, sodass jede Partei in die Gestaltung der Testprozesse einbezogen wurde.
Fazit
In der Praxis hat diese Teststrategie hohe Anerkennung durch den Kunden erhalten und führte stets zu erfolgreichen Releases. Es erfolgten nach Go-Live wenige bis gar keine Incidentmeldungen, sodass auch hier eine Akzeptanz bei den Bankmitarbeitern geschaffen wurde. Die Teststrategie findet nun auch bei anderen agilen Projekten des Kunden Anwendung.
