Automatisierte Tests einer Webanwendung sind Skripte, die nach jeder Codeänderung selbst prüfen, ob die wichtigsten Funktionen noch laufen. Im Vertrag mit einem Software House sollten mindestens drei Dinge stehen: Unit-Tests, End-to-End-Tests für die kritischen Pfade und deren Ausführung in einer CI-Pipeline. Dieser Ratgeber richtet sich an Auftraggeber, die keinen Code lesen und trotzdem Angebot und Testumfang beurteilen müssen. Sie finden hier die Testarten in einfacher Sprache, eine sinnvolle Reihenfolge der Automatisierung und eine Liste mit Fragen an den Dienstleister.
Inhaltsverzeichnis
Was sind automatisierte Tests einer Webanwendung und was hat der Auftraggeber davon?
Es ist Code, der anderen Code prüft. Er läuft von selbst, ohne dass ein Tester sich durch die Bildschirme klickt. Ein manueller Tester geht das Szenario jedes Mal neu durch und kommt bei häufigen Änderungen schlicht nicht hinterher (oder lässt etwas aus, weil es Freitag nach 16 Uhr ist). Ein Automat wiederholt dieselben Schritte immer gleich, in wenigen Minuten, bei jeder Korrektur. Was hat das Unternehmen davon? Weniger Fehler in der Produktion, ruhigere Releases neuer Funktionen und einen leichteren Wechsel des Dienstleisters in Zukunft, weil das neue Team sofort sieht, was kaputtgeht. Tests sind Teil der Qualität, kein Extra. Wer sie weglässt, landet bei einem der typischen Probleme, über die wir beim Thema Fehler bei der App-Entwicklung schreiben.
Testarten: Unit-, Integrations-, End-to-End- und Regressionstests
Jede Art prüft die Anwendung auf einer anderen Ebene, von einer einzelnen Funktion bis zum kompletten Weg des Nutzers. Die Unterschiede sollten Sie kennen, denn in Angeboten werden die Begriffe oft durcheinander verwendet:
- Unit-Tests - prüfen eine einzelne Funktion isoliert, z. B. die Preisberechnung mit Rabatt. Sie laufen in Sekundenbruchteilen. Geschrieben werden sie von Entwicklern, oft mit Werkzeugen wie PHPUnit oder Jest.
- Integrationstests - prüfen, wie Bausteine zusammenarbeiten: die Anwendung mit der Datenbank, dem Zahlungsanbieter, einer externen API. Sie sind langsamer, weil mehrere Systeme gleichzeitig beteiligt sind.
- End-to-End-Tests (E2E) - spielen einen Menschen im Browser nach und gehen den ganzen Weg vom Klick bis zum Ergebnis durch. Beispiele für Werkzeuge sind Playwright und Cypress. Sie dauern am längsten und werden von Entwicklern oder Testautomatisierern geschrieben.
- Regressionstests - keine eigene Technik, sondern ein Ziel: sicherstellen, dass eine neue Änderung nichts kaputt gemacht hat, was vorher funktioniert hat. Erreicht wird es durch alle oben genannten Tests, die zusammen laufen.
Die Testpyramide: wie viel wovon
Die Regel ist einfach. Am meisten schnelle Unit-Tests, weniger Integrationstests und am wenigsten langsame E2E-Tests, die in der Pflege teuer sind. Ein Projekt, das nur auf E2E setzt? Langes Warten auf Ergebnisse, Tests, die bei jeder Designänderung brechen, und mühsame Suche nach der Fehlerursache. Nur Unit-Tests reichen aber auch nicht, denn sie finden keine Probleme an den Schnittstellen zwischen Modulen oder im Browser. Und Vorsicht bei einer Code-Coverage in Prozent, die als Vorgabe im Vertrag steht. Sie sagt nur, wie viel Code ausgeführt wurde. Sie sagt nicht, ob das geprüft wurde, was fürs Geschäft wichtig ist.
Was zuerst automatisieren? Die kritischen Pfade der Anwendung
Zuerst kommen die Pfade, deren Ausfall das Geschäft stoppt: Login, Zahlung, Speichern von Daten. Aus meiner Sicht ist diese Reihenfolge sinnvoll:
- Login, Registrierung und Benutzerrechte.
- Zahlung und Bestellabschluss (Checkout).
- Speichern, Bearbeiten und Abrufen der wichtigsten Daten.
- Integrationen mit externen Systemen.
- Geschäftsberechnungen: Preise, Rabatte, Steuern.
Und womit warten? Mit Ansichten, die sich in der MVP-Phase jede Woche ändern, mit der reinen Optik und mit einmaligen Funktionen. Da ist die Zeit schade. Der Testumfang soll mit dem Produkt wachsen, das sieht man gut, wenn man sich die Phasen beim Aufbau einer Webanwendung von der ersten Version bis zur Skalierung ansieht.
Wann die Tests laufen: Tests in CI/CD
In einem sauber aufgesetzten Projekt starten die Tests bei jeder Änderung im Repository von selbst, in der CI-Pipeline, bevor der Code auf den Server kommt. CI, also Continuous Integration, ist ein Automat: Der Entwickler schickt Code, und der Automat baut die Anwendung und startet die Tests. Ein rotes Ergebnis blockiert das Deployment. Der Fehler bleibt also beim Entwickler hängen und nicht beim Kunden. Meist laufen zuerst die schnellen Unit-Tests, die E2E-Tests starten auf der Testumgebung kurz vor der Veröffentlichung in der Produktion. Und bei der Arbeit in Sprints, typisch für agiles Projektmanagement in der IT, läuft nach jeder Iteration die komplette Regression.
Automatisierte Tests in Vertrag und Angebot: was Sie den Dienstleister fragen sollten
Der Vertrag sollte klar sagen: welche Testarten entstehen, welche Pfade sie abdecken, wo sie laufen und wer sie nach der Abnahme pflegt. Stellen Sie dem Software House vor der Unterschrift diese Fragen:
- Welche Tests sind im Angebot enthalten?
- Welche Pfade bekommen E2E-Tests?
- Laufen die Tests in der CI und blockieren sie das Deployment bei einem Fehler?
- Bekomme ich den Testcode und Zugriff auf die Ergebnisse?
- Wer aktualisiert die Tests bei Änderungen an der Anwendung?
- Wie sieht die Testumgebung aus und woher kommen die Daten darin?
Warnsignale? Die Antwort „wir testen vor dem Deployment manuell“ ohne jede Automatisierung. Keine Tests im Repository. Tests als kostenpflichtiges Extra ohne festgelegten Umfang. In der Praxis bespricht man den Testumfang am besten schon im ersten Gespräch über das Projekt, egal ob es um Softwareentwicklung nach Maß oder um KI-basierte Anwendungen geht.
Automatisierte Tests einer Webanwendung gehören als Klausel in den Vertrag und nicht als mündliches Versprechen. Das Minimum ist kurz: Unit-Tests für die Geschäftslogik, End-to-End-Tests für die kritischen Pfade und alles zusammen in der CI bei jeder Änderung. Mit so einer Klausel lassen sich Angebote leichter vergleichen, das Projekt leichter abnehmen und in Ruhe weiterentwickeln.
Häufige Fragen
Braucht eine kleine Anwendung oder ein MVP automatisierte Tests?
Ja. Zumindest für Login, Zahlung und das Speichern von Daten, denn ein Ausfall dort trifft sofort die Nutzer. Den Rest kann man später mit Tests abdecken, wenn sich das Produkt stabilisiert hat. So ein schlankes Set schützt die wichtigsten Pfade ohne hohe Kosten zum Start.
Was unterscheidet End-to-End-Tests von Unit-Tests?
E2E-Tests prüfen den ganzen Weg des Nutzers im Browser, Unit-Tests eine einzelne Funktion isoliert. Die ersten zeigen, dass der Prozess als Ganzes funktioniert. Die zweiten zeigen schnell, welcher Teil der Logik versagt hat. Man braucht beide Arten, eine Wahl gibt es hier nicht.
Wer pflegt die Tests nach der Übergabe der Anwendung?
Das hängt vom Vertrag ab, also sollte man es dort genau festlegen. Eine gute Klausel: Die Tests sind Teil des Codes, der an den Auftraggeber übergeben wird, und werden bei jeder Änderung im Rahmen des Supports aktualisiert. So verlieren sie nach den ersten Korrekturen nicht ihren Wert.
