Testautomatisierung: End-2-End-Tests in agilen Softwareprojekten

testautomatisierung

Qualifizierte Softwaretests sind heute wichtiger als je zuvor. Allerdings nicht mehr am Ende der Entwicklungszeit, sondern als Teil agiler Prozesse fortlaufend im Projekt. Das schreit geradezu nach Testautomatisierung, auch für umfangreichere End-2-End-Tests.

Qualifizierte Softwaretests waren lange Zeit Nebensache und Testautomatisierung kaum ein Thema. Schließlich testet jeder Entwickler auch selbst, warum also noch einen weiteren umfangreichen Prozess ins Projekt aufnehmen? Warum noch mehr Ressourcen mit solchen „Overhead“-Aufgaben blockieren? Und in welchen Sprint soll das?

„Getestet wird am Ende.“ (Vom Praktikanten.)

Bei umfangreichen agilen Softwareprojekten gilt das natürlich längst nicht mehr. Continuous integration und continuous delivery heißt eben auch: Continuous testing. Komponenten- und begrenzte Integrationstests werden dabei von den Entwicklerteams selbst erstellt und fortlaufend ausgeführt. Diese interne Testautomatisierung dient in agilen Modellen allerdings 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.

Brauchen wir End-2-End-Tests überhaupt und sollten wir sie automatisieren?

Vollständige End-2-End-Tests durch unabhängige Tester soll und kann das Komponententesting 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. Hier besteht die Chance auch die Fehler zu entdecken, die bei isolierten Komponententests nicht auffallen.

Solche End-2-End-Tests sind gerade für komplexe Browser-Anwendungen unerlässlich – und eine Herausforderung zugleich. Die Testpläne umfassen oft etliche Kombinationen aus OS, Browser und Hardwareausstattung, und für jede müssen unzählige Seitenaufrufe, Klicks, Scrolls und Formulareingaben getestet werden. Ohne Testautomatisierung mit Lösungen wie Selenium wäre das innerhalb von CI/CD Prozessen kaum zu bewältigen, auch nicht für große Expertenteams, die ausschließlich mit dem 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 testgetriebene Entwicklung. Das lässt sich meist einfacher in agile Prozesse integrieren als End-2-End-Tests.

Was gegen Testautomatisierung spricht und was dafür

Dass bei jedem Merge die Testpläne angepasst werden müssten, ist ein häufiges Argument gegen automatisierte End-2-End-Tests. So kann schon bei kleinen Änderungen an einem User Interface ein Test 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 bei 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, dass es wieder heißt: „Getestet wird am Ende.“

In agilen Software-Projekten ist das mit dem „Ende“ aber so eine Sache. Hier gibt es viele Enden 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. Sie 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 es gefixed ist.

Automatisierte End-2-End-Tests bedürfen also guter Planung, Pflege und Disziplin. Das gilt für interne Testpläne ebenso wie für die Arbeit externer Tester. Ist das Vorgehen aber einmal gelernt und integriert, wird kein Qualitätsmanager mehr darauf verzichten wollen.

So funktionieren automatisierte Tests:

Auch interessant:
Google Testing Blog über End-2-End-Tests

[Full disclosure: Sevenval bietet ISTQB-zertifiziertes Testing von Funktionalität, Usability, Performance und Barrierefreiheit, End-to-End automatisiert für den gesamten Software-Lebenszyklus. Mehr Informationen über unsere Leistungen.]

 

Zur Blog-Startseite