Nicht selten wird die Testautomatisierung in der Projektaufwandsplanung und ihrem Beitrag zur Qualität des Endprodukts unterschätzt. Häufig wird sie ans Ende eines Software-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 Änderungen am Programmcode auf die Nutzer:innen auswirken. Auf diese Weise werden implementierte Tests automatisch und regelmäßig ausgeführt und Zeitersparnisse gegenüber dem manuellen Testen gewonnen. Darüber hinaus lassen sich damit auch Status und Fortschritt des Projekts im Zeitverlauf betrachten. Mit einem Testframework, das an die GitLab Continuous Integration (CI) angebunden und als fester Bestandteil der Deployment-Pipeline etabliert ist, kann dies umgesetzt werden.
Wir werden im Folgenden auf klassisches und agiles Testen eingehen und darauf, welche Möglichkeiten und Herausforderungen das agile Testen mit sich bringt. In einem zweiten Teil werden wir darauf aufbauend anhand der Gitlab Continuous Integration (CI) zeigen, wie GUI-Tests in eine Deployment Pipeline integriert werden können.

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 Planung der Testphase verwendet 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 wären sie zeitnah entdeckt worden. 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. Am Ende jedes Sprints soll immer ein funktionsfähiges Produkt stehen, dass im nächsten Sprint wieder um weitere Features ergänzt wird. 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 und notwendig, damit ein funktionierendes Programm ausgeliefert werden kann. Die kurze Feedbackschleife im Fall von gefundenen Fehlern 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 mit sich, die jedoch 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, zu einem späteren Zeitpunkt fehlschlagen. Das nicht unbedingt, weil die getestete Software-Fehler enthält, sondern häufig auch, weil der Test auf das vorherige Verhalten des Programms zugeschnitten war. 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 gründlich dokumentiert zu haben, um darauf zurückzugreifen, falls Anpassungen notwendig werden. Besonders im Umgang mit modernen Javascript-Frameworks können unerwartete Fehler auftreten, da dort oft vieles “unter der Haube” passiert. Hier führt die schnelle Feedbackschleife zur zeitnahen Erkennung von nötigen Anpassungen. Enge und zeitnahe Kommunikation zwischen dem Entwicklungs- und dem Testteam sind 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 neu 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 der Endnutzer:innen 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.

Fazit: Die optimale Teststrategie ist projektabhängig

Testen in traditionell am Wasserfallmodell ausgerichteten Projekten oder agilen Projekten unterscheidet sich vor allem in der zeitlichen Positionierung der Tests im Projektablauf. Traditionell stehen die Tests am Ende des Projekts, in agilen Kontexten werden sie in jeden Sprint mit einbezogen. So kann das Programm Sprint für Sprint erweitert und auch in jedem dieser Sprints bereits auftretende Fehler gefunden und gemeldet werden. In Projekten mit niedrigem Veränderungspotential und von Beginn an klaren Anforderungen hingegen kann das Wasserfallmodell durchaus ein gangbarer Weg sein.
 

Die Autoren:

Marvin Sommer arbeitet als Berater und Testdesigner bei der viadee Unternehmensberatung AG unter anderem an der Konzeption und Umsetzung von automatisierten Tests.

Simon Damrau arbeitet als Test Designer und Test Analyst bei der viadee Unternehmensberatung AG. In seiner Rolle als Berater arbeitet er an der Analyse, Konzeption und Umsetzung von (teil-)automatisierten Tests.