Frühzeitiges Testen spart Kosten

In der Anfangsphase und der Sprint Planung werden die Akzeptanzkriterien definiert, das heißt es wird herausgearbeitet, was gemäß den gestellten Anforderungen überprüft werden soll. Diese Akzeptanzkriterien bilden die Grundlage für die durchzuführenden Tests. In jedem neuen Sprint werden die Kriterien und dementsprechend auch die Tests ergänzt. In der Test-Charta werden Testziele und mögliche Testideen zusammengefasst.

Im Anschluss startet der Sprint und alle relevanten Tests werden vorbereitet, das heißt, die Testdaten und die Testumgebung werden bereitgestellt und anschließend werden die Tests ausgeführt. Dies geschieht parallel zur Entwicklung der Features. In den täglichen Scrums werden Testblocker oder Testhindernisse mit dem Scrum Team besprochen. Fehler, die durch die Tests gefunden werden, werden direkt behoben.

Die Entwickler erstellen Unit-Tests und führen diese auf Basis der testgetriebenen Entwicklung aus (test-driven development), eine Kerntechnik des Extreme Programming. Dabei werden konsequent die Tests noch vor den Komponenten geschrieben, die man eigentlich testen möchte (Test-First). Durch das rechtzeitige Refactoring wird sich auf das Wesentliche konzentriert und kein unnötiger Code auf Vorrat erstellt. Erst bei erfolgreich durchlaufenden lokalen Unit-Tests wird der Code und die Testfälle eingecheckt, so wird sichergestellt, dass alles perfekt funktioniert, bevor es in einem Build landet. In dem Build wird sämtlicher Code integriert und zusammen getestet. Das geschieht täglich mehrmals in einem „Daily Build“, welches vor Freigabe automatisch in der Continuous Delivery Pipeline getestet wird.

Eine Continuous Delivery Pipeline umfasst Continuous Integration, Delivery und Deployment und wird oft als CI/CD-Pipeline bezeichnet. Die CI/CD-Pipeline ist ein Teilbereich einer größeren Toolkette, welche automatisiertes Testen und Versionsverwaltung beinhaltet. Continuous Delivery Pipelines bewegen den Anwendungscode vom Entwickler zum User, dabei ist die Testautomatisierung die Grundlage aller modernen Delivery-Pipelines. Nach den erfolgreichen Unit-Tests checkt der Entwickler den neuen/ aktualisierten Code ein und eine Reihe von automatisierten Tests startet. Diese sollte sowohl Integrationstests als auch Systemtests mit funktionalen und nicht-funktionalen Tests beinhalten, die beispielsweise die Performance, Vernetzung, externe APIs, Abhängigkeiten und die Sicherheit überprüfen. Dies verhindert, dass instabiler, riskanter oder unsicherer Code veröffentlicht und an den User ausgegeben wird. Erst wenn diese Tests erfolgreich abgeschlossen werden, startet der automatisierte Build Prozess. Besonders die nicht-funktionalen Tests haben eine lange Laufzeit, daher ist es sinnvoll nicht alle Tests bei jedem Daily Build einzuplanen, sondern eine Auswahl dafür zu bestimmen. Alle aufwändigeren Tests können beispielsweise wöchentlich oder vor einem bestimmten Release durchgeführt werden. Gleiches gilt für den Systemintegrationstest, auch dort sollte nur bei Bedarf getestet werden – zum Beispiel bei Anbindung einer neuen Schnittstelle an das System.

Im Sprint vor einem Release finden die Systemtests auf produktionsnaher Umgebung statt, gegebenenfalls mit einem Abnahmetest des Fachbereiches. Sind diese Tests erfolgreich abgenommen, wird das Produkt zum Release in die Produktionsumgebung an DevOps (Development Operations) oder ITIL (Information Technology Infrastructure Library) übergeben. Zentrale Einheiten stellen teamübergreifend Services mit Basisaufgaben für den Test zur Verfügung, wie zum Beispiel dem Bereitstellen von Testumgebungen und Testdaten, der Wartung von Testtools oder der Anbindung an andere Anwendungen.

Natürlich gibt es auch bei der Testautomatisierung bei dem agilen Vorgehen im Vergleich zu dem klassischen Vorgehen ebenfalls gravierende Unterschiede. In klassischen Projekten, die nach dem Wasserfall oder V-Modell strukturiert sind, steht meist erst zum Projektende eine umfangreiche Testphase an. In agilen Projekten muss die Software hingegen nach jedem Sprint einer Testphase und Qualitätskontrolle unterzogen werden.

Anders als bei den oben genannten sequenziellen Vorgehensweisen ist in agilen Projekten die Einführung von automatisierten Tests eine Voraussetzung für ein erfolgreiches Projekt. Während nach jedem Sprint die Software weiterwächst, nimmt ebenso die Anzahl der Tests und der Testaufwand zu. Um eine möglichst große Testabdeckung der Software im Projektverlauf zu gewährleisten, muss vom Beginn an, der Aufbau eines Frameworks zur Testautomatisierung und eine CI/CD-Pipeline eingeplant werden. Auch wenn zum Anfang des Projekts der Testumfang geringer ausfällt und sich die Tests auf die unteren Testebenen für Komponenten- und Modultests beschränken, bieten vorab festgelegte Kriterien des Frameworks die Grundlage für eine gelungene Implementierung.

Dass ein agiles Projekt nicht ohne Testautomatisierung machbar ist, stellt sich spätestens bei der Stufe des Systemtests heraus. Bei jedem Sprint werden im Systemtest nicht nur die neuen Funktionen überprüft, sondern es müssen auch alle bisherigen Funktionalitäten als Regressionstest berücksichtigt werden. Während Entwickler vielleicht noch in der Lage wären, nach jedem Sprint einen Modultest durchzuführen, würde der manuelle Systemtest jeden Aufwands-, Zeit- und Budgetrahmen eines agilen Projekts sprengen. Die entwickelte Software nimmt mit jedem Sprint an Funktionsumfang und Komplexität zu – im gleichen Umfang wächst jedoch auch die Anzahl und Komplexität der Tests, insbesondere der Systemtests. Durch die Testautomatisierung und einer funktionierende CI/CD-Pipeline kann dieser Testaufwand signifikant reduziert werden.

Für den manuellen Systemtest nach jedem Sprint fehlt es den Mitarbeitern meist an Zeit. Am Ende eines agilen Projektes ohne Testautomatisierung könnten dann plötzlich und überraschend Fehler auftreten. Daher ist es in agilen Projekten umso wichtiger, von Beginn an ein automatisiertes und strukturiertes Testframework zu implantieren, welches gemeinsam mit der Software wächst. Und nicht vergessen: je früher getestet wird, desto früher können auch mögliche Fehler behoben werden und desto geringer sind die Kosten des gesamten Entwicklungsprozesses.