Testautomatisierung: End-2-End-Tests in der agilen Softwareentwicklung

Qualifizierte Softwaretests sind heute wichtiger als je zuvor. Allerdings nicht mehr am Ende der Entwicklungszeit, sondern als agiles Testing fortlaufend im Projekt. Durch Testautomatisierung können auch umfangreiche End-2-End-Tests unterstützt werden.

Software-Testing unerlässlich für agile Softwareentwicklung

Qualifizierte Softwaretests waren lange Zeit Nebensache und Testautomatisierung kaum ein Thema. Jeder Entwickler war für das Software-Testing selbst verantwortlich, also warum einen weiteren umfangreichen Prozess ins Projekt aufnehmen? Warum noch mehr Ressourcen mit solchen “Overhead”-Aufgaben blockieren?

“Getestet wird am Ende (vom Praktikanten).”

In der agilen Softwareentwicklung gilt das natürlich längst nicht mehr. CI/CD (Continuous Integreation / Continuous Delivery) bedeutet eben auch: Continuous-Testing. Komponenten- und begrenzte Integrationstests werden dabei von den Entwicklerteams selbst erstellt und fortlaufend ausgeführt.

Diese interne Testautomatisierung dient als agiles Testing weniger der klassischen Qualitätskontrolle als der Steuerung des Softwaredesigns. So kann man etwa schnell herausfinden, welche Auswirkungen ein neues Feature auf bestehende Komponenten hat.

Sind End-2-End-Tests bei agilem Testing notwendig?

Vollständige End-2-End-Tests durch unabhängige Software-Tester soll und kann dieses agile Testing von Komponenten aber nicht ersetzen. Denn erst hier wird das finale Zusammenspiel aller Komponenten einer harten Qualitätskontrolle unterzogen: von der eigentlichen Anwendung über genutzte Datenbanken und grundlegende Infrastrukturen bis hin zur Software auf Client-Seite, etwa einem Browser.

Durch End2End-Testing besteht die Chance auch die Fehler zu entdecken, die bei isolierten Komponententests nicht auffallen.

End-2-End-Tests sind daher gerade für komplexe Web-Anwendungen unerlässlich – und eine Herausforderung zugleich. Die Testpläne umfassen oft etliche Kombinationen aus OS, Browser und Hardwareausstattung. Für jede dieser Kombinationen müssen unzählige Seitenaufrufe, Klicks, Scrolls und Formulareingaben getestet werden.

Sollten End-2-End-Tests durch Testautomatisierung umgesetzt werden?

Ohne Testautomatisierung mit Lösungen wie Selenium wären diese ausführlichen End2End-Tests innerhalb von CI/CD-Prozessen kaum zu bewältigen, auch nicht für große Expertenteams, die ausschließlich mit dem Software-Testing beauftragt sind.

Den Aufwand für End-2-End-Tests zur besseren Qualitätssicherung scheuen jedoch noch viele Unternehmen. Zum Ausgleich intensivieren sie andere Tests und setzen etwa auf eine testgetriebene Entwicklung. Das lässt sich meist einfacher in agile Prozesse integrieren als End-2-End-Tests.

Das spricht gegen Testautomatisierung in End-2-End-Tests

Ein häufiges Argument gegen automatisierte End-2-End-Tests sind die wiederkehrenden Anpassungen von Testplänen, die z.B. durch einen Merge notwendig werden können. So kann das Software-Testing schon bei kleinen Änderungen an einem User-Interface mehrere Fehler produzieren.

Das hemmt die Entwicklungsgeschwindigkeit und hat zur Konsequenz, dass Fehler generell einfacher toleriert werden.

Zudem ist es oft alles andere als trivial, von den durch End-2-End-Tests gefundenen Fehlern auf konkrete Stellen im Quellcode der getesteten Anwendung zu schließen. Als Fehlerquelle in Frage kommen alle Bestandteile des genutzten Systems, von der angebundenen Datenbank bis zum Browser.

Gegen die Testautomatisierung wird also vor allem angeführt, dass sie kaum Zeitersparnis bringe, weil Setup, Ausführung und Ergebnisanalyse eben aufwändig seien. Das alles ist nur dann wahr, wenn der End-2-End-Test überfrachtet ist. Und dann ist es kein Wunder, wenn es wieder heißt: “Getestet wird am Ende.”

Stattdessen Testautomatisierung gezielt für End-2-End-Tests einsetzen

In der agilen Softwareentwicklung gibt es aber kein definitives Ende und deshalb sind fortlaufende End-2-End-Tests sinnvoll, will man eine gleichbleibende Qualität während des gesamten Software-Lebenszyklus erreichen.

Um diese erfolgreich in CI/CD-Prozesse einzubauen, sollten sie vor allem für übergreifende Integrationsaspekte genutzt werden und nicht für Funktionalitätstests einzelner Bestandteile. Diese sind in zielgerichteten kleineren Tests viel besser aufgehoben.

Besteht ein neues Feature den Komponententest oder Integrationstest nicht, bleibt es beim Merge außen vor, bis ein Fix gefunden wurde.

Testautomatisierung für End2End bedarf also guter Planung, Pflege und Disziplin. Das gilt für interne Testpläne ebenso wie für die Arbeit externer Software-Tester. Ist das Vorgehen aber einmal gelernt und integriert, wird kein Qualitätsmanager mehr darauf verzichten wollen.

So funktionieren automatisierte Softwaretests

Avenga bietet ISTQB-zertifiziertes Software-Testing von Funktionalität, Usability, Performance und Barrierefreiheit, End-to-End automatisiert für den gesamten Software-Lebenszyklus.

In diesem Video sehen Sie, wie wir bei Avenga (vormals Sevenval) die Testautomatisierung von End2End-Tests vornehmen:

Automated-Testing: Das sagen unsere Experten

404, drei Zahlen, die bei Entwicklern Angstschweiß auslösen. In der Testumgebung lief alles noch wunderbar, dann kam der Push in das Produktiv-System und plötzlich ging gar nichts mehr. Wie konnte das passieren?

Durch Automated-Testing sollen Maßnahmen in den Produktionskreislauf eingebunden werden, die während der Entwicklung, vor dem Live-Gang und im laufenden Betrieb Warnungen und Hinweise liefern, damit sich Situationen wie oben nicht ereignen.

Wie der Name schon sagt, werden diese Maßnahmen automatisiert durchgeführt, also durch Skripte und Programme. So erhoffen sich viele Entwickler, Zeit und Ressourcen einsparen zu können, die durch manuelles Software-Testing entstehen würden.

Klingt zu schön, um wahr zu sein? Unsere Experten aus den Bereichen QA, Entwicklung und Sales gehen dem Thema “Automated-Testing” auf den Grund.

Markus Meyer, Head of Quality Assurance bei Avenga

Automated-Testing in der Software-Entwicklung bedeutet für mich: alle Maßnahmen zur Bewertung von Software, die nicht manuell durchgeführt werden. Von Health-Checks im Monitoring über Unit-Tests in der Entwicklung bis hin zu End2End-Tests durch Quality-Engineers. Ein weit verbreiteter Mythos ist, dass dadurch per se Ressourcen und Aufwand gespart würden. Das stimmt aber nur, wenn bereits ein entsprechender Aufwand in manuelle Qualitätsmaßnahmen gesteckt wird.

Die Stärke automatisierter Testings liegt darin, dass sie die Aufwände für wiederkehrende Quality-Tätigkeiten minimieren und Ergebnisse schneller präsentieren können. Frei werdende Ressourcen werden dann sinnvollerweise in die Tätigkeiten transferiert, die ein noch höheres Qualitätsniveau bringen. Dann ist es langfristig billiger und besser. Dabei immer beachten: Was für den Computer richtig oder falsch ist, muss zuvor durch den User festgelegt werden. DON’T PANIC!

Angelina Farsch, Key Account Manager bei Avenga

Werden durch Automated-Testing die laufenden Kosten geringer? Klares ‘Jein’! Durch Monitoring und Tools kann sichergestellt werden, dass die Webseite einer permanenten Überprüfung standhält. Damit wird der Aufwand aber nicht reduziert – höchstens beim Chef, der nicht jeden Morgen als erstes die Webseite auf Verfügbarkeit checkt. Es sorgt aber dafür, dass Ausfälle schneller bemerkt und behoben werden können. Bei immer komplexer werdenden Anwendungen wird das bald ein Must-have sein. Dabei ist der Automatisierungsgrad von Testing-Aktivitäten immer noch relativ niedrig. Manche Firmen führen deshalb ein Test-Excellence-Center ein, das als zentrale Instanz innerhalb des Unternehmens fungiert.

Manuel Schiller, Software Developer bei Avenga

Automated-Testing hat sowohl Vorteile als auch Nachteile: Auf der einen Seite bietet es die Möglichkeit, wirklich End2End gegen eine API zu testen. Damit kann man zum Beispiel Änderungen an der API frühzeitig feststellen. Zudem kann man dadurch eine Webseite über mehrere Browser und Mobilgeräte stabil halten. Das ist vor allem dann wertvoll, wenn z.B. auf mobilen Geräten die nativen Inputs genutzt werden. Auf der anderen Seite ist die Gefahr hoch, „Umfaller“ in der Testbatterie zu haben, z.B. durch API-Ausfälle und lange Antwortzeiten. Außerdem sind die Testlaufzeiten hoch: Die Tests durchlaufen die Website wie ein User (Clicks, Tastenanschläge, Seitenaufbau). Damit benötigen sie ein Vielfaches der Zeit, die zum Beispiel bei SPA übliche Snapshot-Tests mit Jest oder ähnlichen Frameworks betragen würden.

Whitepaper zum Qualitätsmanagement in der Softwareentwicklung

Ihr digitales Produkt weist Fehler auf, die meist zufällig entdeckt werden? Die Behebung dauert ewig? Und neue Funktionen verursachen neue Probleme am bestehenden Produkt? Dann wird es höchste Zeit für Ihr Unternehmen, ein „Quality Mindset“ zu etablieren!