Kriterien für die Anwendbarkeit von „continuous everything“

Die heutige IT-Welt verlangt stets nach den neusten Technologien und Ansätzen. Für die größtmögliche Flexibilität werden immer mehr Projekte agil umgesetzt. DevOps löst die Probleme an der Schnittstelle zwischen Entwicklung und Betrieb. Der maximale Automatisierungsgrad kann nicht hoch genug sein. Und natürlich soll der aktuelle Zustand der Anwendung zu jeder Zeit bekannt sein – Continuous Testing, Monitoring, Deployment, Integration und Delivery. Ist das alles sinnvoll?

Um dies beurteilen zu können, sollten wir mit einem einheitlichen Verständnis der Begrifflichkeiten beginnen. Laut Duden bedeutet kontinuierlich: ununterbrochen, lückenlos, zusammenhängend. Im Kontext von Continuous Integration/Continuous Deployment (CI/CD) bedeutet dies zum Beispiel, dass der Entwickler seinen Code, welchen er lokal entwickelt, direkt in die zentrale Codeablage (Repository) seiner Anwendung „pusht“. Sofern der folgende Merge-Request keine Konflikte verursacht, wird die Hauptbranch (alter Main Code plus Neuentwicklung, Feature Branch) direkt in den produktiven Betrieb veröffentlicht (deployt). Die produktive Anwendung ist kontinuierlich auf dem neusten Stand.

Um dies mit gewünschter Qualität und unter Sicherstellung der angeforderten Funktion realisieren zu können, ist es jedoch notwendig, dass auch der Test weitestmöglich automatisiert und kontinuierlich durchgeführt wird. Auf diese Art und Weise kann sichergestellt werden, dass die neue Version der Software stets die gewünschten Funktionen gewährleistet und den Anwendern die gewohnte Qualität (Design, Usability, Performance usw.) bietet. Hierfür ist es notwendig, dass die Qualitätssicherung (QA) Bestandteil jedes Schrittes im Softwarelebenszyklus ist, wie Abbildung 1 zeigt.

Aus fachlicher Sicht ist zu berücksichtigen, dass der Wert des continuous Tests stark von den gegebenen Rahmenparametern abhängt. Tabelle 1 beschreibt Bedingungen, welche für und gegen den kontinuierlichen Testansatz sprechen. Wenn für die Anwendung kein Bedarf besteht, dass der Zustand des Systems zu jeder Zeit bekannt ist, schnelle Release-Zyklen nicht benötigt werden, da nur zweimal pro Jahr gepatcht wird, oder die notwendigen Skills im Entwicklungsteam nicht vorhanden sind, so ist der kontinuierliche Testansatz für das Projekt nicht der richtige Weg.

Wenn die Software jedoch mehrmals täglich aktualisiert und auf Schwachstellen gescannt wird, sowie ein hoher Automatisierungsgrad grundsätzlich erreichbar ist, so bietet der continuous Testansatz viele Möglichkeiten, diese Anforderungen zu bedienen. Das folgende Beispiel wird die Bedingungen im Kontext eines Szenarios darstellen, um die Entscheidung greifbarer zu machen.

Herausforderungen und Vorzüge am Beispiel des fiktiven Softwareprojekts Tripplaner

Tripplaner ist eine Routenplaner-Anwendung, welche für Smartphones, Web-Browser und in dedizierten KFZ-Systemen erhältlich ist. Die Anwendung bietet ihren Nutzern die Möglichkeit, Reisen und Trips entlang ihrer Bedarfe zu planen, und berücksichtigt die aktuelle Verkehrssituation, unterschiedliche Verkehrsmittel sowie Nutzerwünsche wie „Panorama Route“ oder „schnellste Route“. Der Tripplaner wird täglich von Hunderttausenden Nutzern verwendet und ist die etablierte Kartensoftware für viele Nutzergruppen, wie zum Beispiel Pendler und Außendienstmitarbeiter. Die Anwendung wird monatlich um neue Features ergänzt, welche durch Community-Feedback und Verbesserungsmöglichkeiten aus dem Entwicklungsteam entstehen. Darüber hinaus erfordern Anpassungen, welche sich nicht durch Einspeisung in die Datenbank lösen lassen, einen höheren Entwicklungsaufwand. Die dadurch entstehende hohe Anzahl an Deployments und die heterogene Infrastruktur machen das System aufwendig zu warten und weiterzuentwickeln.

Der Tripplaner benötigt, aufgrund der Vielzahl seiner Funktionen, unterschiedliche Microservices, welche die einzelnen Aufgaben erledigen. Darüber hinaus gibt es ein Web-Frontend, eine nicht-relationale Datenbank, eine mobile Anwendung (jeweils für iOS und Android), eine Client-Anwendung für die Fahrzeuge sowie einen serverless AWS-Dienst, welcher ständig nach neuen Daten fragt. Alle Dienste sind in der AWS-Cloud gehostet (siehe Abbildung 2).

Die Divergenz dieser Beispielsoftware kombiniert mit der hohen Zahl an Aktualisierungen und der hohen Nutzerzahl stellen uns vor folgende Herausforderungen:

Aufgrund der heterogenen Produktlandschaft sind unterschiedliche Entwicklungsteams involviert, welche die verschiedenen Anwendungen beziehungsweise die Microservice-Infrastruktur (weiter-)entwickeln und warten. Die Schnittstellen zwischen allen Anwendungen und Microservices müssen hierbei abgestimmt und integrativ getestet werden. Ein übergreifender, automatisierter Test ist sehr umfangreich, da für die Testadaptionsschichten verschiedene Technologien benötigt werden. Hinzu kommt, dass häufig Anpassungen vorgenommen und zügig veröffentlicht (released) werden müssen. Jede Neuentwicklung und Änderung bringt neue Testfälle mit sich, erfordert aber auch die Ausführung des Regressionstestsets. Das kann bei einer häufigen Anzahl an Releases und niedrigem Automatisierungsgrad schnell sehr aufwendig und zeitintensiv werden. Hier kann der Einsatz einer CI/CD-Pipeline mit den zugehörigen Modulen der Qualitätssicherung für einen effizienten Ablauf und schnelle Release-Zyklen sorgen. Abbildung 3 zeigt, wie so eine CI/CD-Pipeline strukturell aufgebaut sein könnte.

Allgemein lässt sich sagen, dass ein höherer Grad an Automation für dieses Produkt sinnvoll ist. Es werden schnelle Feedback- und Release-Zyklen benötigt. Die verschiedenen Produktteams müssen ihre Dienste integrativ miteinander testen, da das System recht komplex ist und viele Anwendungsfälle bietet, welche durch Regressionstests geprüft werden. Darüber hinaus sorgt das hohe Nutzeraufkommen für unterschiedliche Performanz-Szenarien. Dem entsprechend sollte die Lastverteilung für diese Kriterien permanent geprüft und beobachtet werden.

Für die Umsetzung wird unterschiedlichste fachliche Expertise benötigt, welche kombiniert zu einer erheblichen Qualitätssteigerung und schnelleren Delivery-Pipelines führt. Damit dies in einer finanziell angemessenen Weise umgesetzt werden kann, muss gebündeltes Wissen in Themengebieten, wie DevOps, Softwareentwicklung, Testautomation und Testmanagement, vorhanden sein. In der jüngeren Vergangenheit wurden diese Kompetenzen durch unterschiedliche Mitglieder des Projektteams abgebildet. Im Rahmen der Verbreitung agiler Entwicklungsvorgehen bilden sich jedoch immer mehr cross-funktionale Teams heraus, welche als Team gemeinsam die notwendigen Kompetenzen abbilden, um kontinuierliche Entwicklung und Qualitätssicherung zu ermöglichen.

Was lässt sich hieraus generell für den continuous Testansatz ableiten?

Der kontinuierliche Ansatz ist im Hinblick auf die Minimierung manueller Tätigkeiten und die Geschwindigkeiten der Feedbackzyklen an Effizienz nur schwer zu überbieten. Dies gilt besonders für technisch moderne Anwendungen, welche kurze Release-Zyklen haben, aus verteilten Systemen und Microservices bestehen, und unter Berücksichtigung der vorhandenen Infrastruktur und der notwendigen Skills im Team.

Auch bei der Zusammenarbeit verschiedener Teams an einem Systemkomplex, bei welchem mindestens auf Testumgebungen häufig deployt wird, bietet der kontinuierliche Testansatz bereits einen großen Mehrwert. Bei der aktuellen technologischen Entwicklung und der Art der Zusammenarbeit werden kontinuierliche Ansätze immer beliebter. Gleichzeitig darf nicht vergessen werden, dass besonders bei großen Firmen viele Systeme in die Jahre gekommen sind und weder die Infrastruktur einen kontinuierlichen Ansatz unterstützt noch die Release-Frequenz dies erforderlich macht. Es sollte beim Aufsatz der Teststrategie geprüft werden, ob ein kontinuierlicher Ansatz nach diesen Gesichtspunkten möglich und sinnvoll ist.

Die Aufwände, welche „Continuous Everything“ initial mit sich bringt, werden durch die gesteigerte Liefergeschwindigkeit ausgeglichen. Dies setzt eine grundsätzliche Reife des Qualitätssicherungsvorgehens im Projekt voraus. Die integrierten Built-in-Quality-Methodiken führen langfristig zu einer Qualitätssteigerung. Durch den Einsatz von Blueprints können Automatismen wiederverwendbar gemacht und somit effiziente Out-of-the-Box-Lösungen geschaffen werden. Standardisierung der Qualitätssicherung entlang der Blueprints führt hierbei zu einer Effizienzsteigerung der Testautomationswerkzeuge und der Ergebnisse im Test.

Wann ist Continuous Testing sinnvoll?

Abhängig vom System-under-Test und von den Rahmenbedingungen kann continuous Testing einen Mehrwert für die Entwicklung und die Qualitätssicherung darstellen. Dies sollte jedoch anhand definierter Kriterien vorab geprüft werden. Die Vorteile eines kontinuierlichen Testansatzes wurden im Verlauf des Artikels bereits beleuchtet. Es ist der Vollständigkeit halber hinzuzufügen, dass dieser Ansatz nicht zwangsläufig zu einer Kostenreduktion der Qualitätssicherung führen wird. Ziel ist es, die Lieferzeiträume zu verkürzen bei gleichbleibender bis steigender Qualität.

Da Zeit jedoch ein elementarer Faktor in der Entwicklung und Verbesserung von Softwareprodukten ist, bietet der kontinuierliche Entwicklungs- und Testansatz viele Vorteile, welche schon jetzt und auch für die Zukunft relevant sein werden.

Die Softwareentwicklung hat sich in den vergangenen Jahren stark verändert und die Qualitätssicherung, als Bestandteil des SDLC, muss weiterhin ein vergleichbares Qualitätsniveau liefern. Schnelle Entwicklungszyklen erfordern schnelle Feedbackzyklen. Um dies effizient zu gewährleisten, wird es auch in Zukunft Weiterentwicklungen auf dem Weg zu „Built-in-Quality“ geben und Continuous Testing auf die nächste Ebene heben.

Die Autoren