End-to-End-Tests einfach erklärt: was vor jedem Release geprüft wird

Bevor eine neue Version Ihrer Software live geht, muss jemand sicherstellen, dass alles, was die Leute täglich damit tun, noch funktioniert. Ein End-to-End-Test erledigt das automatisch: Ein Programm bedient Ihre Software so, wie es ein Mensch tun würde, vom ersten Klick bis zum Ergebnis, und meldet, ob es geklappt hat.

Was ist ein End-to-End-Test?

Ein End-to-End-Test öffnet Ihre Software in einem echten Browser, meldet sich an, klickt, tippt und prüft, was auf dem Bildschirm erscheint. Weil er die fertige Software mit allen Teilen zusammen nutzt, zeigt er, ob das Ganze funktioniert, nicht nur jeder Teil für sich. Werkzeuge wie Playwright führen diese Tests in den Browser-Engines hinter Chrome, Firefox und Safari aus und können ein Handy nachahmen.

Ein Beispiel aus der Software für eine Schreinerei: Ein Test meldet sich als Mitarbeiter im Büro an, erstellt eine Offerte für eine Küche, schickt sie dem Kunden und prüft, ob die Offerte nun als versendet angezeigt wird. Bricht ein Schritt ab, schlägt der Test fehl und zeigt, wo.

Genau das finden solche Tests. Ein Knopf reagiert nach einem Update nicht mehr, ein Formular speichert nichts, eine E-Mail wird nie verschickt, eine Ansicht wird nur auf dem Handy falsch angezeigt, oder eine neue Funktion blockiert unbemerkt einen älteren Schritt. Jeder dieser Fehler kann allen kleineren Tests entgehen und Ihr Team trotzdem an der Arbeit hindern.

Wie unterscheidet er sich von anderen Tests?

Er testet die ganze Software so, wie ein Mensch sie nutzt, während andere Tests kleinere Teile für sich prüfen. Testleitfäden, darunter der von Google, beschreiben drei Arten automatisierter Tests:

• Unit-Tests prüfen ein kleines Stück Code für sich allein, etwa die Berechnung, die einer Rechnung die Mehrwertsteuer hinzufügt. Sie sind klein und schnell, und eine gute Testsammlung enthält viele davon.
• Integrationstests prüfen, ob zwei Teile zusammenspielen, etwa die Software und ihre Datenbank.
• End-to-End-Tests prüfen einen ganzen Ablauf durch die fertige Software, in einem Browser.

End-to-End-Tests geben die grösste Sicherheit, dass die Software funktioniert. Sie sind aber auch langsam, brauchen viel Pflege und schlagen manchmal aus Gründen fehl, die mit einem echten Fehler nichts zu tun haben. Darum raten Testleitfäden, nur wenige davon einzusetzen und sie auf das Wichtigste zu richten. Der Testing-Blog von Google schlug 2015 als erste Schätzung eine Aufteilung von 70 % Unit-Tests, 20 % Integrationstests und 10 % End-to-End-Tests vor und fügte an, dass die genaue Mischung von Team zu Team verschieden ist.

Ein weiterer Test ist gar nicht automatisiert: Sie selbst, wenn Sie die Software vor dem Livegang ausprobieren. Darum sollte Ihre Software zuerst in einer Testversion laufen, die Sie ausprobieren können, mit denselben Ansichten, die Ihr Team nutzen wird.

Was sollte vor einem Release getestet werden?

Die Abläufe, auf die Ihr Geschäft angewiesen ist. Eine nützliche Frage für jeden davon: Würde es uns Geld oder Vertrauen kosten, wenn das morgen nicht mehr funktioniert? Die Liste könnte so aussehen:

• die Anmeldung und was jede Rolle sehen und tun darf
• der Hauptablauf von Anfang bis Ende, etwa eine Bestellung, eine Offerte oder eine Freigabe
• alles, was etwas verschickt: E-Mails, Rechnungen, Dokumente
• Zahlungen, falls die Software welche entgegennimmt
• die meistgenutzten Ansichten, auf dem Handy wie am Computer

Ham Vockes Leitfaden «The Practical Test Pyramid» auf der Website von Martin Fowler gibt denselben Rat: Suchen Sie die Abläufe, die den Kernwert Ihres Produkts tragen, und machen Sie aus ihren wichtigsten Schritten End-to-End-Tests. Die Sonderfälle gehören in die kleineren Tests darunter.

Diese Tests sollten vor jedem Release laufen, in einer Testversion und nicht auf der Live-Software. Bei uns läuft Ihre Software zuerst in einer Testversion, die Sie ausprobieren können. Dort testen wir sie gründlich, durchgängig von Anfang bis Ende, und sie geht erst live, wenn alles funktioniert.

Wem gehören die Tests nach der Übergabe?

Die Tests gehören zu Ihrer Software. Sie sind für sie geschrieben, prüfen ihr Verhalten, und wer sie später ändert, braucht sie, um zu wissen, dass nichts kaputtgegangen ist. Eine saubere Lieferung enthält sie, zusammen mit der Dokumentation.

Was Sie am Ende erhalten und zu welchen Bedingungen, wird in der Offerte vereinbart, lesen Sie diesen Teil also vor der Unterschrift. Fragen Sie drei Dinge: Gehören die automatisierten Tests zur Lieferung, kann jemand anders als der ursprüngliche Entwickler sie ausführen, und gibt es eine kurze Anleitung dazu? Die Rechte am Code sind eine eigene Frage, die der Beitrag Wem gehört der Code? erklärt.

Tests sind auch lange nach dem Livegang wichtig. Jedes Sicherheitsupdate verändert die Software ein wenig, und die OWASP Top 10 von 2025 zählen es zu den Anzeichen einer wahrscheinlich angreifbaren Anwendung, wenn Entwickler die Verträglichkeit aktualisierter oder gepatchter Bibliotheken nicht testen. Tests, die mit der Software geliefert werden, machen jedes Update prüfbar. Mehr zur Zeit nach dem Livegang im Beitrag über die Wartung von Software nach dem Livegang.

Wo stossen Tests an Grenzen?

Tests zeigen, dass die Abläufe, an die jemand gedacht hat, noch funktionieren. Sie können nicht zeigen, dass sonst nichts falsch ist. Der Informatiker Edsger W. Dijkstra brachte es 1972 in seiner Turing-Vorlesung auf den Punkt: Testen kann sehr wirksam zeigen, dass Fehler vorhanden sind, ist aber hoffnungslos ungeeignet, um zu zeigen, dass es keine gibt.

Ein Test kann auch fehlschlagen, ohne dass etwas falsch ist: wegen des Timings, einer Animation oder eines unerwarteten Dialogs. Solche Fehlalarme müssen behoben werden, sonst verlieren die Leute das Vertrauen in die Tests.

Darum gehören zwei Dinge neben die Tests:

• Ihr eigenes Ausprobieren in der Testversion, wo Ihnen auffällt, wofür kein Test geschrieben wurde.
• Monitoring nach dem Livegang, das die Live-Software zu festen Zeiten prüft und Alarm schlägt, wenn etwas ausfällt, denn manche Probleme zeigen sich erst im echten Einsatz.

Ein Test, der vor einem Release fehlschlägt, ist eine gute Nachricht: Er hat das Problem vor Ihren Nutzern gefunden.