Warum agile Software-Entwicklung Testautomatisierung braucht

In diesem Beitrag geht es um die Herausforderungen der Testautomatisierung in agilen Software-Projekten und wie Entwicklungsteams ihnen begegnen können. Am Beispiel des Testframeworks mateo und der GitLab Continuous Integration wird aufgezeigt, wie sich Testautomatisierung in die Deployment-Pipeline einbinden lässt. 

Nicht selten wird die Testautomatisierung im Projektmanagement und ihrem Beitrag zur Qualität des Endprodukts unterschätzt. Häufig wird sie ans Ende eines Projekts geschoben, damit möglichst wenig Zeit und Budget während der Entwicklung darauf verwendet werden. Gerade in agilen Software-Projekten, in denen regelmäßig Produktinkremente ausgeliefert werden, bietet die Testautomatisierung große Vorteile. So können durch die Integration in den Deployment-Prozess für jedes Inkrement Tests angestoßen werden, die Auskunft darüber geben, wie sich die Änderung am Programm auf die Nutzer:innen auswirkt. Auf diese Weise werden implementierte Tests automatisch und regelmäßig ausgeführt und Zeitersparnisse gegenüber dem manuellen Testen gewonnen. Das Testframework mateo kann an die GitLab Continuous Integration (CI) angebunden und für die Deployment-Pipeline genutzt werden.

Klassisches und agiles Testen

Dem inkrementellen, agilen Ablauf eines Projekts steht das klassische Wasserfallmodell gegenüber – auch hinsichtlich der Softwaretests. Das Wasserfallmodell verfolgt einen zu Projektbeginn geplanten, linearen Ablauf. Die verschiedenen Phasen der Entwicklung werden sequenziell abgearbeitet, wobei die Oberflächentests am Ende stehen und das fertige Produkt prüfen. Alle Anforderungen an das Projekt sind von Beginn an bekannt und können für die Testphase geplant werden. Durch diese zeitliche Trennung von Entwicklung und Test fallen Fehler, die am Anfang der Entwicklung entstanden sind und durch Unit-Tests nicht abgedeckt werden können, erst sehr spät auf und sind für die Entwicklung schwieriger nachzuvollziehen, als wenn sie zeitnah entdeckt worden wären. Das heißt nicht, dass das klassische Testen und das Wasserfallmodell nur Nachteile bringen. Für Projekte mit klaren Anforderungen und niedrigem Veränderungspotential bieten sie einen strukturierteren und effizienteren Weg als die agile Variante.

In einem agilen Umfeld dreht sich hingegen alles um schnelle, inkrementelle Auslieferung der Software in sogenannten Sprints. In diesen zwei- bis vierwöchigen Zyklen wird das Produkt um Funktionalitäten erweitert, ausgeliefert und durch stetiges Feedback bei Bedarf angepasst. Das bedeutet, es können sich von Sprint zu Sprint neue Anforderungen ergeben, die implementiert und auch beim Test berücksichtigt werden müssen. Testen in einem agilen Umfeld bedeutet daher, dass die Tests nicht wie im Wasserfallmodell gesammelt am Ende der Entwicklung erstellt und durchgeführt werden, sondern in jedem Inkrement parallel zur Entwicklung stattfinden. Dadurch ist ein zeitnahes Entdecken von Fehlern in jedem Sprint möglich. Es erleichtert den Entwickler:innen sich technisch und fachlich in die Problemsituation hineinzuversetzen, da der zugehörige Code meist erst kurz zuvor geschrieben wurde.

Herausforderungen des agilen Testens

Das agile Testen bringt einige Herausforderungen, die jedoch auch große Vorteile bieten. Zum einen bedeutet agiles Testen, dass die Tester:innen mit einer agilen Entwicklung zusammenarbeiten und Änderungen am Produkt in der Regel zeitnah umgesetzt werden. Dadurch kann es immer wieder vorkommen, dass Tests, die bereits fertiggestellt und geprüft wurden, fehlschlagen. Nicht unbedingt, weil die getestete Software Fehler enthält, sondern weil der Test auf das vorherige Verhalten des Programms zugeschnitten ist. Solche Änderungen bedeuten auch, dass zu neuen und/oder angepassten Features im Programm noch kein Testkonzept existiert und kurzfristig erarbeitet werden muss. Hier ist es wichtig, die bereits existierenden Tests dokumentiert zu haben, um darauf zurückzugreifen, falls Anpassungen notwendig werden. Besonders im Umgang mit modernen Javascript-Frameworks führt diese schnelle Feedbackschleife zur zeitnahen Erkennung von nötigen Anpassungen, da hier oft vieles unter der Haube passiert, was die Kommunikation zwischen einem Testframework wie mateo und der Testumgebung, wie einer zu testenden Webseite, kompliziert macht. Enge und zeitnahe Kommunikation zwischen dem Entwicklungs- und dem Testteam ist der Schlüssel zum Erfolg.

Eine weitere Herausforderung beim agilen Testen ist es, mehrere zusammenhängende Programmteile zu testen, von denen noch nicht alle fertiggestellt wurden. Durch die agile Entwicklung kann es vorkommen, dass Funktionalitäten mit niedriger Priorität erst zu einem späteren Zeitpunkt implementiert werden und im Rahmen der Testdurchführung noch nicht existieren. Wird z. B. das Kontaktformular einer Webseite getestet, während die Validierung von E-Mail-Adressen noch nicht implementiert ist, kann diese noch nicht getestet werden. Es muss ein neuer Test für die Validierung geschrieben oder der bestehende Test muss angepasst werden, sobald diese Funktionalität geliefert wird. Auch Testdaten müssen so kontinuierlich generiert werden, da bei neu hinzukommenden Features nicht von vornherein ein Testablauf mit zugehörigen Testdaten existiert.

Durch diese kurzfristigen Inkremente im Test wird einerseits verhindert, dass Fehler bis zum Ende der Entwicklung unbemerkt bleiben. Darüber hinaus bieten automatisierte Oberflächentests in agilen Projekten die Möglichkeit, durch die Betrachtung der Nutzeroberfläche bereits frühzeitig die Sicht des Endnutzers zu prüfen. So können Darstellungsprobleme und -bugs auffallen, die von Komponententests (Unit-Tests), die nur die Funktionen einzelner Codekomponenten testen, nicht abgedeckt werden können.

Testen mit mateo und der GitLab Continuous Integration (CI)

GitLab bietet die Möglichkeit, Änderungen am Projekt nachzuvollziehen und zu historisieren. Dazu wird das Projekt in einem git Repository abgelegt von dem sich jede:r Entwickler:in eine Kopie in die lokale Entwicklungsumgebung herunterladen kann. So können lokal Änderungen vorgenommen und später über einen sogenannten Push in das git Repository eingefügt werden, sodass sie auch allen anderen Entwickler:innen zur Verfügung stehen. Bei einem Push kann dazu eine Liste von Aufgaben angestoßen werden, die automatisch ausgeführt werden, bevor die Änderung im Repository akzeptiert wird. Über diese Aufgaben, die in einer Pipeline nacheinander ablaufen, können z. B. Tests, Build-Prozesse und letztendlich das Deployment, also die Bereitstellung ausgeführt werden. 

Bevor ein neues Inkrement der Software veröffentlicht wird, sollte es natürlich getestet worden sein. Sonar- und Unit-Tests sind bereits in vielen Deployment-Pipelines ein etablierter Bestandteil und prüfen die Funktionalität des Quellcodes selbst. Sie decken somit nur das Backend ab und spiegeln nicht wider, was die Endnutzer:innen sehen und wie sie die Anwendung bedienen. An dieser Stelle stehen die GUI-Tests, die sich ebenso in eine Pipeline integrieren und somit bei jedem Push ausführen lassen. Durch diese Integration in den Deployment-Prozess kann für jedes Software-Inkrement bereits automatisiert getestet werden, ohne dass die Tests manuell getriggert werden müssen. Damit an dieser Stelle immer der Code der zur Pipeline gehörenden Version der Anwendung getestet wird, muss er dediziert gebaut, gestartet und der Testumgebung zur Verfügung gestellt werden. Dasselbe gilt für etwaige Datenbanken und Dienste, die das Programm benötigt. In der GitLab CI kann das zum Beispiel über Services in einem Kubernetes-Cluster realisiert werden. Die Tests prüfen dadurch immer den Code, der zur laufenden Pipeline gehört. Das genutzte Testframework gibt dabei einen Exit-Code zurück, der das Ergebnis des Pipeline-Jobs darstellt und in der Pipeline-Übersicht Erfolg oder Fehlschlag der Tests anzeigt. mateo lässt sich dafür als Testframework sehr gut verwenden. Durch das Einbinden von mateo als Service in der Pipeline wird mateo gestartet, führt alle gewünschten Tests aus, stellt die entstehenden Reports als Download bereit und liefert als Rückgabewert den Status Erfolg oder Fehlschlag. Hierfür lassen sich auf Wunsch auch mehrere Gruppen von Tests gleichzeitig ausführen, um die Laufzeit in der Pipeline zu verringern. Dabei gibt jede Testgruppe ihren eigenen Status zurück und stellt Downloads separat bereit.

mateo erlaubt es ebenso, die Testergebnisse automatisch in einer Datenbank zu sammeln und bietet damit eine einfache Möglichkeit, den zeitlichen Verlauf der Pipeline-Erfolge darzustellen. Dabei schreibt mateo nach jedem ausgeführten Test einen Eintrag in eine Datenbank, der Auskunft darüber gibt, wie lange der Test dauerte, wann er gestartet wurde und welche Testschritte erfolgreich waren und welche nicht. Diese Daten können dann zur Auswertung der Gesamtheit der Tests genutzt werden.

Langfristig gute Software-Qualität durch Testautomatisierung

Durch die Integration der Testautomatisierung in die Deployment-Pipeline kann die entwickelte Software bei jeder neuen Änderung automatisch getestet werden. Das ist sowohl im Laufe der Entwicklung als auch in Produktion ein großer Bonus. mateo lässt sich hierfür als Service in eine Pipeline einbinden und kann dort mehrere Testgruppen gleichzeitig ausführen. Während der Entwicklung findet für jedes auf den Development-Branch gepushte Feature bereits Qualitätssicherung statt und die Tests wachsen gemeinsam mit der Anwendung. Diese Regelmäßigkeit nimmt besonders in agilen Projekten einen großen Stellenwert ein, wird in Bezug auf das Testen jedoch häufig unterschätzt. Durch das Ausführen der Oberflächentests in der Pipeline wird die Software explizit stetig geprüft. Das verhindert ein Ansammeln von Fehlern, die von Komponententests nicht abgedeckt werden können. Diese Früherkennung ermöglicht eine schnelle Reaktion und beugt somit dem verspäteten Auffallen von Fehlern nach der Entwicklung oder gar beim Kunden vor.

Nehmen die Änderungen, die am System vorgenommen werden, mit der Zeit ab, werden auch die Testausführungen weniger. Dann kann z. B. durch einen Nightly-Build, d.h. eine nächtliche automatische Ausführung der Pipeline und somit auch der Tests, eine regelmäßige Prüfung der Software realisiert werden und Fehler werden weiterhin zeitnah aufgedeckt.

Nachdem in diesem Teil 1 beschrieben wurde, wie sich Testautomatisierung in die Deployment Pipeline einbinden lässt, beleuchtet Maarten de Klerk in Teil 2 die Bedeutung von Integrationstests in agilen Projekten.

Mehr erfahren:

• Einen einführenden Beitrag zu Agilen Methoden gibt es hier: Agile Methoden und Scrum – einfach erklärt!
• Im Artikel Fünf Schritte zur Continuous Integration zeigen wir am Beispiel Jenkins, wie man eine neue CI aufsetzt. 
• Durch eine flexible Architektur setzen Sie mit mateo core End-to-End-Tests entlang von Geschäftsprozessen in einer heterogenen Anwendungslandschaft um.