End-to-End-Test

Software besteht fast immer aus vielen Einzelteilen. Bei einem Online-Shop sind das zum Beispiel die Webseite, die Suchfunktion, die Datenbank mit den Artikeln und der Bezahldienst. Jedes dieser Teile kann für sich getestet werden. Ein End-to-End-Test macht etwas anderes: Er läuft einmal durch die ganze Kette, vom einen Ende bis zum anderen. Ein automatisches Programm klickt sich dabei durch die Seite wie ein Kunde, sucht ein Produkt, legt es in den Warenkorb und bezahlt. Am Ende prüft es, ob die Bestellbestätigung erscheint und die Bestellung wirklich gespeichert wurde.

Fehler, die erst im Zusammenspiel auftauchen

Die gefährlichsten Fehler entstehen selten in einem einzelnen Bauteil. Sie entstehen an den Übergängen dazwischen. Ein Beispiel: Der Bezahldienst erwartet den Betrag in Cent, die Webseite schickt ihn in Euro. Beide Teile arbeiten für sich völlig korrekt. Trotzdem zahlt der Kunde plötzlich das Hundertfache.

Solche Fehler sieht man nur, wenn man den kompletten Ablauf durchspielt. Genau darin liegt der Wert dieser Tests. Sie sind die letzte Kontrolle, bevor eine Änderung an echte Nutzer geht. Große Anbieter veröffentlichen mehrmals täglich neue Versionen ihrer Software. Ohne automatische Durchläufe wäre dieses Tempo nicht zu verantworten.

Der Preis dafür ist hoch. End-to-End-Tests sind langsam, weil sie echte Systeme starten und auf Antworten warten. Sie schlagen außerdem manchmal fehl, ohne dass ein echter Fehler vorliegt – etwa weil eine Seite eine Sekunde länger lädt. Solche unzuverlässigen Tests nennen Entwickler « flaky ». Man baut deshalb wenige End-to-End-Tests für die wichtigsten Abläufe und viele schnelle Tests für die Einzelteile.

Wie ein Testdurchlauf abläuft

Ein End-to-End-Test wird als Programm geschrieben, meist in wenigen Dutzend Zeilen. Darin steht eine Abfolge von Anweisungen: Öffne diese Adresse, tippe diesen Text in dieses Feld, klicke diesen Knopf. Danach folgen Prüfungen, sogenannte Assertions. Sie halten fest, was hinterher zu sehen sein muss, zum Beispiel der Satz « Vielen Dank für Ihre Bestellung ».

Ausgeführt wird das von Werkzeugen wie Playwright, Cypress oder Selenium. Sie steuern einen echten Browser, nur ohne Fenster auf dem Bildschirm. Der Browser tut also genau das, was ein Mensch täte, nur schneller und immer identisch. Bei einem Fehlschlag speichert das Werkzeug ein Bildschirmfoto und ein Video des Ablaufs. So kann man nachsehen, an welcher Stelle es schiefging.

Damit die Tests nicht in echten Systemen einkaufen, arbeiten sie in einer Testumgebung. Das ist eine Kopie der Anwendung mit erfundenen Daten und einem Bezahldienst im Übungsmodus. Ausgelöst werden die Durchläufe automatisch, sobald jemand neuen Programmcode einreicht. Ist ein Test rot, wird die Änderung nicht veröffentlicht.

E2E-Tests bei KI-Produkten und in Firmenmeldungen

Als Nutzer bemerkt man diese Tests nur indirekt – nämlich dann, wenn sie gefehlt haben. Eine Banking-App, in der die Überweisung nach einem Update abbricht, ist ein typischer Fall. In Berichten über solche Störungen ist oft von « lückenhafter Testabdeckung » die Rede. Gemeint ist damit meist genau dieser fehlende Durchlauf über die gesamte Kette.

Bei KI-Produkten ist die Sache besonders knifflig. Ein Sprachmodell antwortet auf dieselbe Frage nicht immer mit denselben Worten. Ein Test kann deshalb nicht auf einen exakten Satz prüfen. Stattdessen prüft man gröbere Eigenschaften: Kommt überhaupt eine Antwort? Enthält sie die gesuchte Zahl? Bleibt sie unter der erlaubten Wartezeit? Manche Teams lassen ein zweites Modell die Antwort bewerten.

Verwechseln sollte man den End-to-End-Test nicht mit dem Unit-Test. Ein Unit-Test prüft ein winziges Codestück isoliert und läuft in Millisekunden. Der End-to-End-Test prüft das Ganze und braucht Sekunden bis Minuten. Beide gehören zusammen: Der eine sagt dir, welches Teil kaputt ist, der andere, ob das Produkt für den Nutzer noch funktioniert.