Ein Softwareteam, das jede Änderung von Hand testet, stößt schnell an eine Grenze: Mit jeder neuen Funktion wächst die Zahl der Fälle, die erneut geprüft werden müssten, und die Zeit dafür wächst mit. Testautomatisierung löst genau dieses Problem. Ein Programm schreibt dabei keinen eigenen Test, sondern führt zuvor festgelegte Prüfroutinen selbstständig aus und meldet, wenn sich das Verhalten der Software ungewollt verändert hat.
3 Ebenen automatisierter Software-Tests
Drei Testebenen kommen dabei am häufigsten vor. Ein Unit-Test prüft eine einzelne Funktion oder Methode isoliert, ohne die restliche Anwendung mitlaufen zu lassen. Ein Integrationstest prüft, ob mehrere Komponenten wie eine Datenbankanbindung und eine Programmierschnittstelle korrekt zusammenspielen. Ein End-to-End-Test simuliert die komplette Nutzung einer Anwendung, etwa einen Warenkorb-Kauf von der Produktseite bis zur Bestellbestätigung, so wie ein echter Kunde ihn durchlaufen würde.
Jedes fünfte Testteam automatisiert drei Viertel seiner Tests
Der State of Testing Report 2025, eine jährliche Befragung von Testerinnen und Entwicklern weltweit, zeigt, wie weit sich das Verfahren durchgesetzt hat. 26 Prozent der befragten Teams ersetzen inzwischen bis zur Hälfte ihrer manuellen Tests durch automatisierte, weitere 20 Prozent automatisieren drei Viertel oder mehr. Nur noch 14 Prozent der Teams geben an, dass Automatisierung ihren manuellen Testaufwand gar nicht verringert hat, 2023 lag dieser Anteil noch bei 26 Prozent. Die kontinuierliche Testausführung, also das automatische Anstoßen von Tests bei jeder Codeänderung, stieg im selben Zeitraum von 16 auf über 50 Prozent.
Frühere Fehlererkennung durch automatisierte Testläufe
Ein automatisierter Test kostet beim ersten Schreiben Zeit, danach läuft er beliebig oft ohne weiteren Aufwand. Das verschiebt den Zeitpunkt, an dem ein Fehler auffällt: Ein automatisierter Testlauf, der bei jeder Codeänderung startet, findet eine fehlerhafte Funktion oft innerhalb von Minuten, während ein rein manueller Testzyklus erst kurz vor der nächsten Veröffentlichung ansteht. Wer einen Fehler früh findet, behebt ihn, bevor andere Teile des Codes darauf aufbauen, und spart sich damit die aufwendigere Fehlersuche in einem größeren, bereits verzweigten System.
Gleichzeitig deckt Automatisierung Fälle ab, die von Hand kaum wirtschaftlich zu prüfen wären: hunderte Kombinationen aus Eingabewerten, mehrere Browser- oder Betriebssystemversionen, wiederholte Lastspitzen. Ein Mensch, der dieselbe Eingabemaske zum fünfzigsten Mal mit demselben Ablauf testet, wird nachlässiger. Ein Skript nicht.
Werkzeuge für automatisierte Tests
Welches Werkzeug passt, hängt von der Testebene ab. Für Unit-Tests in Java hat sich JUnit etabliert, für Python pytest. Für Weboberflächen testet Selenium seit 2004 browserübergreifend, Microsoft veröffentlichte 2020 mit Playwright eine schnellere Alternative, die auch Chromium, Firefox und WebKit steuert. Cypress konzentriert sich auf Tests direkt im Browser und liefert dabei Video- und Screenshot-Protokolle jedes Testlaufs mit.
| Testebene | Verbreitete Werkzeuge | Prüft |
|---|---|---|
| Unit-Tests | JUnit, pytest | Einzelne Funktionen isoliert |
| Oberflächentests | Selenium, Playwright, Cypress | Bedienung über den Browser |
| Kontinuierliche Ausführung | GitHub Actions, GitLab CI, Jenkins | Automatischer Testlauf bei jeder Codeänderung |
Automatisierte Tests in der Continuous-Integration-Pipeline
Eine Continuous-Integration-Pipeline, kurz CI-Pipeline, verbindet Testautomatisierung mit der täglichen Arbeit im Team. Sobald jemand neuen Code einreicht, startet die Pipeline automatisch die passenden Tests und meldet das Ergebnis direkt an die Entwicklerin oder den Entwickler zurück, meist innerhalb weniger Minuten. Werkzeuge wie GitHub Actions, GitLab CI oder das ältere Jenkins übernehmen diesen Ablauf. Schlägt ein Test fehl, lässt sich die fehlerhafte Änderung in der Regel sofort auf einen einzelnen Commit zurückführen, weil zwischen zwei Testläufen nur wenige Codezeilen liegen.
Grenzen der Testautomatisierung
Automatisierte Tests prüfen nur, was jemand vorher als Testfall formuliert hat. Ein neuartiger Bedienfehler, den niemand vorausgesehen hat, oder ein Layoutproblem, das nur auf einem bestimmten Bildschirm auffällt, bleibt unentdeckt, bis ein Mensch die Anwendung tatsächlich benutzt. Exploratives Testen durch echte Personen bleibt deshalb Teil einer vollständigen Teststrategie, gerade bei neuen Funktionen, für die noch niemand einen Testfall geschrieben hat. Und ein Testskript, das nicht gepflegt wird, meldet nach einiger Zeit selbst dann einen Fehler, wenn sich nur die Oberfläche geändert hat, der eigentliche Ablauf aber intakt ist. Dieser sogenannte flaky Test, ein Test mit wechselndem Ergebnis ohne echte Ursache im Code, kostet Vertrauen in die gesamte Testsuite, wenn Teams ihn nicht reparieren oder entfernen.
Wer mit Testautomatisierung beginnt, fängt am besten bei den Abläufen an, die am häufigsten ausgeführt werden und deren Ausfall am teuersten wäre, etwa der Zahlungsprozess in einem Onlineshop. Von dort aus lässt sich die Testsuite schrittweise um weitere Testfälle erweitern, statt von Anfang an jeden denkbaren Fall abzudecken.
Häufig gestellte Fragen
Worin unterscheiden sich Unit-Tests, Integrationstests und End-to-End-Tests?
Ein Unit-Test prüft eine einzelne Funktion oder Methode isoliert, ohne die restliche Anwendung mitlaufen zu lassen. Ein Integrationstest prüft, ob mehrere Komponenten wie eine Datenbankanbindung und eine Programmierschnittstelle korrekt zusammenspielen, während ein End-to-End-Test die komplette Nutzung einer Anwendung simuliert, etwa einen Warenkorb-Kauf von der Produktseite bis zur Bestellbestätigung.
Wie hat sich der Anteil automatisierter Tests laut dem State of Testing Report 2025 entwickelt?
26 Prozent der befragten Teams automatisieren inzwischen bis zur Hälfte ihrer manuellen Tests, weitere 20 Prozent drei Viertel oder mehr. Nur noch 14 Prozent geben an, dass Automatisierung ihren manuellen Testaufwand gar nicht verringert hat, 2023 lag dieser Anteil noch bei 26 Prozent, und die kontinuierliche Testausführung bei jeder Codeänderung stieg im selben Zeitraum von 16 auf über 50 Prozent.
Was ist ein flaky Test und warum ist er ein Problem?
Ein flaky Test ist ein automatisierter Test mit wechselndem Ergebnis ohne echte Ursache im Code, etwa weil sich nur die Oberfläche geändert hat, der eigentliche Ablauf aber intakt geblieben ist. Er kostet Vertrauen in die gesamte Testsuite, wenn ein Team ihn nicht repariert oder entfernt, weil sich echte Fehlermeldungen dann kaum noch von Zufallsergebnissen unterscheiden lassen.
Womit sollte ein Team am besten beginnen, wenn es Testautomatisierung einführt?
Am sinnvollsten beginnt ein Team bei den Abläufen, die am häufigsten ausgeführt werden und deren Ausfall am teuersten wäre, etwa dem Zahlungsprozess in einem Onlineshop. Von dort aus lässt sich die Testsuite schrittweise um weitere Testfälle erweitern, statt von Anfang an jeden denkbaren Fall abzudecken.