Hinweis: In der vorherigen Ausgabe vom German Testing Magazin1 haben wir dargestellt, wie sich die DB Netz auf den Weg gemacht hat von einem schweren nachgelagerten Test zu Built-in-Quality. Hierbei war die Entwicklung eines Testprozesses der Schlüssel, der das Umdenken und den Mindswitch hin zu Quality Assurance unterstützt. Doch ein Prozess ist am Ende ein Stück Papier und wird nur gelebt, wenn er in die tägliche Arbeit integriert wird.
Der folgende Artikel zeigt, wie dieser Testprozess durch ein nachhaltiges und zukunftsfähiges Qualitätssicherungs-Framework um eine CI/CD-Pipeline (Abbildung 1) operationalisiert und automatisiert wurde.
Abb. 1: Modular Quality Assurance Pipeline der DB Netz
Wir haben uns bei der DB Netz den Herausforderungen des modernen Testens angenommen und eine langfristige, robuste Testautomatisierungslösung geschaffen: die Modular Quality Assurance Pipeline (MoQ-AP) (siehe Abbildung 1).
1) GTM-2-2021, Seite 9 bis 12, https://webreader.itspektrum.de/de/profiles/7d30f3fc5f62-objektspektrum/editions/german-testing-magazin-02-2021/pages
Vision „Future of Testing” der DB Netz
Im Rahmen der SAFe© Transformation der DB Netz begannen wir, das Umdenken hin zu „Built-in-Quality“ durch unterstützende Prozesse zu ebnen. Prozesse müssen in die tägliche Arbeit inkludiert sein, damit sie gelebt und angewendet werden. Im Kontext von SAFe© und DevOps führt dabei kein Weg an einer kontinuierlich qualitätssichernden CI/ CD-Pipeline vorbei.
Zu Beginn hatten wir viele Fragen: Wie ist es möglich, eine Pipeline-Lösung bereitzustellen, die alle Projektbedarfe bedient? Wie kann kontinuierliche Weiterentwicklung und Wartung aussehen? Wie können wir die Projekte befähigen, CI/CD wertschöpfend zu nutzen?
Kleiner Rückblick zur Ausgangslage
In den letzten zwei Jahren hat sich die IT-Welt stark verändert und DevOps rückt immer mehr in den Fokus. Teams entstehen, in denen alle qualitätssichernden Aktivitäten, Aufbau und Betrieb der Testinfrastruktur verortet werden, anstatt wie früher in separaten Teams mit dedizierten Verantwortungen. Die Silos werden zusammengelegt und erfordern eine E2E-Qualitätssicherungsstrategie.
Doch wie beginnt man den Weg zu einer E2E-qualitätssichernden CI/CD-Pipeline? Zunächst mussten bestehende Toollandschaften und Plattformen berücksichtigt werden, denn eine hochgradige Automatisierung muss sich in diese integrieren. Die Entscheidung für das Kernstück der entstehenden zentralen CI/CD-Pipeline-Lösung fand zwischen Azure DevOps und GitLab-CI statt. Das GitLab-CI-Tool war in verschiedenen Konzern-Projekten bereits im Einsatz und erfüllte die Kriterien der Flexibilität zum Aufbau einer modularen, qualitätssicherungsgetriebenen CI-Pipeline durch die Nutzung von Skript-Templates, welche zugleich individuell anpassbar sind.
Die Wahl der zu nutzenden Cloud-Plattform war hier deutlich aufwendiger, da sich sowohl OpenShift als auch EKS im Einsatz befand. Das Ziel einer zukunftsträchtigen CI/ CD-Pipeline musste ein cloud-agnostischer Ansatz sein, das heißt Lauffähigkeit auf unterschiedlichen Plattformen.
Auf diesen Basisentscheidungen aufbauend, entstand iterativ innerhalb von zwei Jahren die MoQ-AP, eine zentral entwickelte und gewartete CI/CD-Pipeline-Lösung, deren Kern-Features wir nachfolgend vorstellen.
Zusammenspiel der Qualitätssicherungssilos
In agilen Vorgehen ist das Thema „Builtin-Quality“ ein zentraler Bestandteil eines modernen Entwicklungsvorgehens. Um dieses Ziel zu erreichen, muss das Verständnis aufgebaut werden, dass die Verantwortung aller Teststufen und -arten nicht mehr bei separaten Teams liegt. Das Entwicklungsteam übernimmt die Verantwortung für den gesamten Softwareentwicklungszyklus (SDLC). Um die Menge an qualitätssichernden Aktivitäten aus einem Team heraus meistern zu können, ist Automatisierung unumgänglich.
Das Zusammenspiel der verschiedenen Testaktivitäten muss daher vollautomatisiert in CI/CD-Pipelines abgebildet werden. Eine E2E-Teststrategie ist dabei unabdingbar.
Damit diese Testaktivitäten vollumfänglich abgebildet werden können, wird eine gesamtheitliche, abgestimmte Architektur mit verschiedenen Komponenten benötigt. In Abbildung 2 ist ein stark vereinfachtes Architekturbild der MoQ-AP und das Zusammenspiel dieser Komponenten dargestellt.
Abb. 2: Stark vereinfachtes Architektur-Konzept der MoQ-AP
Automatisiertes Teststufenkonzept
Ein Kernelement für die Umsetzung unserer E2E-Teststrategie ist die Abdeckung aller Teststufen und der vielen Testarten nach ISO 25010 innerhalb der MoQ-AP, unter anderen: Komponenten-, Integrations-, System-, E2E-, Security- und LuP-Test.
Die verschiedenen Teststufen und -arten werden dabei über unterschiedliche Module beziehungsweise Kombination dieser abgebildet. Dies ermöglicht eine modulare, an die Projekt-Bedürfnisse angepasste Pipeline. Dieser modulare Ansatz erlaubt flexible Testabfolgen sowie dedizierte Testszenarien, wie zum Beispiel für Mobile Testing.
Um das Teststufenkonzept effizient nutzen zu können, wurde die MoQ-AP befähigt, unterschiedliche Teststufen auf unabhängigen Testumgebungen innerhalb einer CI/CD-Pipeline abzubilden. Auf diese Weise ist es möglich, eine an die Testing-Trophy (siehe Abbildung 3) angelehnte E2E-Pipeline aufzubauen.
Abb. 3: Angepasste Testing Trophy nach Kent C. Dodds
Damit Testautomationsskripte aus früheren Teststufen wiederverwendet werden können, wird das Robot-Framework als übergreifendes Testdefinitionstool in der MoQ-AP eingesetzt. Dies ermöglicht das Ansteuern von API, UI oder auch Datenbank-Komponenten aus einem Framework heraus, unabhängig von den dahinter befindlichen Testautomationstools.
Mit der Abfolge der unterschiedlichen Testumgebungen können darüber hinaus Abbruchkriterien formuliert werden, um beispielsweise das Deployment von Code mit schweren Schwachstellen zu verhindern.
Dynamische autonome Testumgebungen
Bei IT-Projekten sind Effizienz und Kostenreduzierung oft maßgebliche KPIs für Systeme und Anwendungen über den kompletten SDLC. Die MoQ-AP verfolgt daher den Ansatz, Testumgebungen dynamisch zur Laufzeit zu deployen und nach erfolgreicher Testdurchführung diese wieder abzubauen. Kosten für benötigte Ressourcen entstehen damit nur zur Laufzeit.
Ein weiterer Vorteil ist die unkomplizierte Wiederherstellbarkeit von Ausgangsbedingungen, zum Beispiel Zurücksetzung von Daten. Des Weiteren wird die Last auf die Systeme reduziert, während die Pipeline nicht aktiv ist.
Parallele und sequenzielle Testausführung
Um schnelle Feedbackzyklen für die Entwicklungsteams gewährleisten zu können, sollten die verschiedenen Testaktivitäten in einzelne Pipelines aufgeteilt werden. Diese werden dann sequenziell aufgerufen. Innerhalb von SAFe© entwickeln viele Teams an derselben Anwendung. Somit verfügt jedes Team über eigene Pipelines, die in eine gemeinsame Integrationspipeline zusammenlaufen (siehe Abbildung 4).
Abb. 4: Sequenzielle Pipelines
Parallele Pipelines wiederum ermöglichen eine zeitgleiche Ausführung verschiedener Testaktivitäten. Durch die autonomen Testumgebungen ist dabei sichergestellt, dass es nicht zu einer gegenseitigen Beeinflussung der Testergebnisse kommt.
Built-in-Securitytest
tatische Tests sind ein elementarer Bestandteil einer E2E-Teststrategie. Securitytests, wie SCA, SAST und DAST, müssen daher bereits in den Entwicklungsprozess eingebunden sein, um Schwachstellen im Code so früh wie möglich zu identifizieren. Die Entwicklungsteams stellen die 1st-Lineof-Defense dar. Die integrierten Securitytests in der CI/CD-Pipeline unterstützen sie in dieser Aufgabe.
Durch das Teststufenkonzept der MoQ-AP wird sichergestellt, dass die Scantools zum richtigen Zeitpunkt auf der jeweiligen Testumgebung verortet werden, um den größtmöglichen Mehrwert zu erzeugen. Beispielsweise sollten schwere Schwachstellen vor einem Deployment gefunden sein.
Kontinuierlicher LuP & PTA
Last- & Performanztests (LuP) sind für die Stabilität, die Verlässlichkeit und die Sicherheit eines Systems relevant. Ein kontinuierlicher LuP trägt dabei Sorge, frühzeitig Defizite aufzuzeigen.
Da ein LuP kostenintensiv ist, wurde zusätzlich eine Performanztrendanalyse (PTA) implementiert. Sie ermöglicht ein kontinuierliches Monitoring des Lastverhaltens bei gleichbleibenden Lasttreibern. Über die Zeit des Tests ergibt sich somit ein Trend, wie sich das Lastverhalten des Produkts zukünftig entwickeln wird.
Relevanz von Demo-Pipelines
Der Einstieg in das Themenfeld CI/CD ist komplex. Daher ist es hilfreich, eine Demonstration möglicher Einsatzszenarien zur Verfügung zu stellen.
Innerhalb der Demo-Pipelines werden Vorgänge und Module anschaulich dargestellt, unter anderen die Anwendung der MoQ-AP-Module, deren interne Qualitätssicherung sowie die gesamtheitliche Abbildung eines konkreten Projektbeispiels (siehe Abbildung 5).
Abb. 5: Demo-Pipeline GitLab-CI-Ansicht mit parallelen Test-Stages
Innerhalb dieser Demo entstanden auch zu Anschauungszwecken besondere Einsatzszenarien. Beispielsweise existieren Securityszenarien mit einer erhöhten Anzahl an Schwachstellen. Mittels dieser können ebenfalls Analysen durchgeführt werden. So kann zum Beispiel die Effektivität der Konfigurationen verschiedener Security-Rules verglichen werden. Dadurch wurde ersichtlich, dass die einzelnen Rules durchaus unterschiedliche Ergebnisse aufzeigen.
Ein anderes Szenario existiert für Mobile Testing. In diesem Szenario werden reale Endgeräte auf einer Device-Farm über einen Appium-Server angesprochen und eine, zur Laufzeit aufgespielte, Applikation getestet. Das Endgerät wird dabei über eine REST-API, für die Dauer der Testausführung, gebucht und für den Test reserviert.
Der nächste Evolutionsschritt: der Konfigurator
Die MoQ-AP entwickelt sich kontinuierlich weiter auf dem Weg zu „Future of Testing“. Der nächste Schritt wird der Konfigurator sein. Für den Aufbau und den Betrieb der CI/CD-Pipeline wird technisches Know-how benötigt. Um den Einstieg in Continuous Testing zu erleichtern, muss es jedem ermöglicht werden, selbst eine Pipeline „zusammenzusetzen“.
Dabei soll eine Weboberfläche helfen, welche in einem Dialog mit dem Nutzer die benötigten Informationen abfragt. Mit diesem Self-Service sollen vermeidbarer Initial-Aufwand beseitigt und die automatisierbaren Standard-Prozeduren angestoßen werden. Darunter zählen das Beantragen von Zugriffen, Cloudumgebungen und Lizenzen. Das Anlegen einer initialen Pipeline mit vorgegebenen Standards und individuellen Bedarfen wird auf diesem Weg ermöglicht (siehe Abbildung 6).
Abb. 6: Mockup des Konfigurator-Self-Service
Fazit
Unsere Erfahrungen der letzten zwei Jahre haben gezeigt, dass es nicht ausreicht, einen Prozess zu definieren oder eine Pipeline aufzubauen. Es muss eine Änderung der Einstellung bei allen Beteiligten stattfinden. Test darf zukünftig nicht mehr als nachgelagerte Tätigkeit empfunden werden, sondern begleitet den gesamten SDLC. Softwarequalitätssicherung wird durch Integration in die Entwicklung, sowie maximale Automatisierung, zu einem inkludierten Dauerläufer.
Um den Weg zu Continuous Testing weiter auszubauen, benötigen die IT-Projekte Unterstützung, zum Beispiel durch Templates, Support beim Pipelineaufbau, Entwicklung neuer Module oder einfach bei der Wartung dieser, sowie individueller Unterstützung auf dem Weg zum Projekterfolg.
Es wurde deutlich, dass die technische Komplexität, die Freiheitseinschränkung in der Entwicklung durch vorgegebene Module und der Wartungsaufwand einer zukunftsfähigen Qualitätssicherungslösung auch Gegenwind erzeugt. Umso wichtiger ist es aufzuzeigen, wie relevant Continuous Testing für die Zukunft des Testens ist und welche Mehrwerte generiert werden, zusätzlich zu den offensichtlichen Punkten: Erhöhung der Effizienz und Ressourcen- und Kostenreduzierungen durch einen Shift-Left der Testaktivitäten in frühere Entwicklungsphasen.
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.
