Testautomatisierung bedeutet, dass Werkzeuge Testfälle ausführen, Ist- und Soll-Ergebnisse vergleichen und Abweichungen protokollieren, die sonst Menschen von Hand prüfen. Sie spart Zeit bei Prüfungen, die oft wiederholt werden, vor allem bei Regressionstests. Vorher kostet sie Geld für Werkzeuge, Skripte und Wartung. Der ISTQB-Lehrplan Foundation Level sagt es trocken: „Die bloße Anschaffung eines Werkzeugs ist keine Erfolgsgarantie.“ (ISTQB CTFL Lehrplan 4.0.2, 2025)

Für Finanzunternehmen kommen Pflichten aus dem Aufsichtsrecht dazu. In der EU gilt seit dem 17. Januar 2025 die DORA-Verordnung, in der Schweiz für Banken und Wertpapierhäuser das FINMA-Rundschreiben 2023/1. Beide Regelwerke verlangen kontrolliert getestete IKT-Änderungen und eine Trennung von Test- und Produktionsumgebungen (bei DORA über die Delegierte Verordnung 2024/1774).

Kurz gefasst: Testautomatisierung lohnt sich dort, wo dieselben Prüfungen oft und stabil laufen, zuerst bei Regressionstests. Der ISTQB-Lehrplan CT-TAS (2024) rechnet den ROI als Einsparung geteilt durch Investition und warnt: Kurze Projekte erreichen die Gewinnschwelle womöglich nicht. Banken planen Aufsichtspflichten ein: getestete Änderungen und getrennte Umgebungen (EU: DORA, Schweiz: FINMA-RS 2023/1), unter DORA auch anonymisierte Testdaten.

Abbildung 1: Sechs Nutzen und acht Risiken der Testautomatisierung (eigene Darstellung nach ISTQB CTFL)

Was ist Testautomatisierung?

Testautomatisierung ist eine Methode der Software-Qualitätssicherung, bei der Werkzeuge Testaktivitäten übernehmen: Testdaten bereitstellen, Tests ausführen, Ergebnisse vergleichen und berichten. Das ISTQB-Glossar definiert sie als „The conversion of test activities to automated operation“ (ISTQB Glossary, 2026), sinngemäß die Überführung von Testaktivitäten in einen automatisierten Betrieb.

Sie reicht über alle Teststufen, vom Unit-Test bis zum Abnahmetest über Oberfläche oder API. Der Werkzeugbegriff des ISTQB ist breit: Laut CTFL-Lehrplan gilt sogar eine Tabellenkalkulation als Testwerkzeug (ISTQB CTFL v4.0.1, 2024).

Ein automatisierter Test prüft nur, was jemand vorher festgelegt hat: Laut Lehrplan CTAL-TAE v2.0 verifizieren automatisierte Tests nur, wofür sie programmiert sind, und prüfen nur maschinell auswertbare Ergebnisse (ISTQB CTAL-TAE v2.0, 2024). Unerwartete Fehlerbilder finden weiterhin Menschen, etwa im explorativen Test.

Welchen Nutzen bringt Testautomatisierung?

Testautomatisierung bringt laut ISTQB-Lehrplan Foundation Level sechs Nutzen, an erster Stelle die „Zeitersparnis durch Verringerung sich wiederholender manueller Arbeiten“ (ISTQB CTFL Lehrplan 4.0.2, 2025). Die übrigen fünf:

• Wiederholbarkeit: weniger einfache menschliche Fehler.

• Objektivere Bewertung: Messwerte wie die Überdeckung.

• Leichterer Zugang zu Informationen: Ergebnisse fließen in Testmanagement und Berichte.

• Kürzere Laufzeiten: frühere Fehlerfunde, schnellere Rückmeldungen, frühere Releases.

• Mehr Zeit für neue Tests: Tester entwerfen neue, tiefere Tests.

Das Forschungsprogramm DORA (dora.dev), unabhängig von der gleichnamigen EU-Verordnung, nennt manuelle Regressionstests zeitaufwendig, teuer und deshalb einen Engpass im Prozess (dora.dev, 2026). Schnelle, verlässliche automatisierte Testsuiten bringt das Programm mit stabilerer Software und weniger Burnout in Verbindung.

Laut „Software Engineering at Google“ enthielten beim Google Web Server zeitweise mehr als 80 % der Produktions-Deployments nutzerrelevante Fehler, die zurückgerollt werden mussten; nach Einführung einer Testpflicht halbierten sich die Notfall-Deployments innerhalb eines Jahres (Software Engineering at Google, Kap. 11, 2020). Es bleibt ein einzelnes Unternehmensbeispiel.

Welche Risiken und Grenzen hat Testautomatisierung?

Das erste Risiko der Testautomatisierung sind falsche Erwartungen: Der CTFL-Lehrplan setzt „Unrealistische Erwartungen hinsichtlich der Vorteile eines Werkzeugs“ an den Anfang seiner Risikoliste (ISTQB CTFL Lehrplan 4.0.2, 2025). Sieben weitere Risiken folgen dort:

Abbildung 2: Flaky Tests bei Google (Google Testing Blog, 2016)

• Unterschätzter Zeit-, Kosten- und Arbeitsaufwand für Einführung, Skriptwartung und Prozessumstellung

• „Verwendung eines Testwerkzeugs, wenn manuelles Testen besser geeignet ist“

• „Zu starkes Vertrauen in ein Werkzeug, z. B. Vernachlässigung der Notwendigkeit des menschlichen kritischen Denkens“

• Abhängigkeit von einem Hersteller, der aufgibt, das Werkzeug einstellt, es verkauft oder schwachen Support bietet

• Aufgegebene Open-Source-Projekte ohne Updates

• Werkzeuge, die nicht zur Entwicklungsplattform passen

• Werkzeuge, die regulatorische Anforderungen oder Sicherheitsstandards nicht erfüllen

Studien stützen mehrere dieser Risiken. Wiklund et al. zählen Wartungskosten zu den am häufigsten gemeldeten Hindernissen und beschreiben, wie überzogene Erwartungen an einen schnellen ROI dazu führen, dass Teams ihre Automatisierung wieder aufgeben (Wiklund et al., STVR, 2017). In einer Umfrage von Rafi et al. unter 115 Praktikern hielten 45 % die verfügbaren Werkzeuge für schlecht passend (Rafi et al., AST, 2012).

Welche Kriterien zählen bei der Werkzeugwahl?

Ein Testwerkzeug muss zu Ihrer Plattform passen, Ihre Tests bei einem Herstellerausfall mitnehmbar lassen, Ihre Auflagen zu Betrieb, Zugriffsrechten und Nachvollziehbarkeit erfüllen und für Ihr Team bedienbar sein. Gängige Lösungen nebeneinander zeigt der Vergleich der Testautomatisierungs-Tools.

Warum entwerten Flaky Tests eine Automatisierung?

Flaky Tests sind Tests, die bei unverändertem Code mal bestehen und mal fehlschlagen, und sie machen Testergebnisse unglaubwürdig. Google meldete 2016, dass rund 1,5 % aller Testläufe ein „flaky“ Ergebnis lieferten. Fast 16 % der Tests zeigten eine gewisse Flakiness, und etwa 84 % der Wechsel von „bestanden“ auf „fehlgeschlagen“ betrafen einen Flaky Test (Google Testing Blog, 2016).

Teams gewöhnen sich dann an, rote Ergebnisse zu übergehen. Laut „Software Engineering at Google“ verlieren Tests an Wert, sobald sich die Flakiness 1 % nähert (Software Engineering at Google, 2020). Als häufigste Ursache fanden Luo et al. in 161 klassifizierten Korrekturen asynchrones Warten, mit 45 % (Luo et al., FSE, 2014).

Welche Tests sollten Sie automatisieren und welche nicht?

Automatisieren Sie zuerst Tests, die oft laufen, wiederholbar sind und stabile, häufig genutzte Geschäftsabläufe prüfen. Der Lehrplan ISTQB CT-TAS v1.0 nennt dafür Kriterien wie technische Machbarkeit, ausreichenden ROI, Wert häufiger Ausführung und gute Wartbarkeit bei Änderungen des Testobjekts (ISTQB CT-TAS v1.0, 2024).

Der CT-TAS-Lehrplan nutzt diesen Kreditantrag als Lehrbeispiel für schwer automatisierbare Tests und empfiehlt, manuelle Arbeit auf explorative Tests und Rückmeldungen von Endnutzern zu konzentrieren. Alle Kriterien als Prüfliste finden Sie in der Checkliste, welche Tests Sie automatisieren sollten.

Welche Rolle spielt die Testpyramide?

Die Testpyramide hilft bei der Frage, auf welcher Ebene ein Test automatisiert wird. „Die Testpyramide ist ein Modell, das zeigt, dass verschiedene Tests eine unterschiedliche Granularität haben können“, heißt es im CTFL-Lehrplan (ISTQB CTFL Lehrplan 4.0.2, 2025). Martin Fowler empfiehlt deutlich mehr Unit-Tests als langsame Tests über die Oberfläche (Fowler, TestPyramid, 2012).

Google nannte 2015 eine Aufteilung von 70 % Unit-, 20 % Integrations- und 10 % E2E-Tests, ausdrücklich „as a good first guess“ (Google Testing Blog, 2015). Das ist eine Faustregel, keine Norm. Der CT-TAS-Lehrplan nennt die Pyramide ein Mittel für kürzere Laufzeiten und besseren ROI. Die Ebenen im Detail erklärt der Grundlagenartikel zur Testpyramide.

Wie führen Sie Testautomatisierung schrittweise ein?

Sie führen Testautomatisierung in Stufen ein: Strategie festlegen, Investition prüfen, mit einem Pilotprojekt starten, zuerst Regressionstests automatisieren und höhere Kosten während des Parallelbetriebs einplanen. Die Schritte stützen sich auf den ISTQB-Lehrplan CT-TAS v1.0 von 2024 (ISTQB, 2024).

Abbildung 3: Einführung in 8 Schritten (eigene Darstellung nach ISTQB CT-TAS v1.0)

1. Ziel und Umfang festlegen. CT-TAS nennt sieben Punkte, die eine Automatisierungsstrategie abdecken muss (Tabelle unten). Wie Sie das Dokument aufbauen, zeigt der Beitrag zur Teststrategie nach ISTQB.

2. Investition prüfen. CT-TAS nennt vier Kriterien: Einführungskosten (Personal, Hardware, Schulung), Phase im Entwicklungszyklus, erwartete Projektdauer und Wartungskosten. Je früher Sie beginnen, desto besser.

3. Mit einem Pilotprojekt starten. „The use of a pilot project helps determine the tools and viability of selected technologies“, schreibt der Lehrplan (ISTQB CT-TAS v1.0, 2024).

4. Regressionstests zuerst. Laut CT-TAS ist der Regressionstest die einfachste Gelegenheit für den Umstieg.

5. Manuelle Tests vorher prüfen. Automatisieren Sie keinen Regressionstest, der manuell schon scheitert. CT-TAS nennt das Ergebnis verschwendet und unproduktiv.

6. Übergangskosten einplanen. Der Lehrplan warnt: „the project should expect increased costs as both manual testing and automated testing take place simultaneously.“

7. Bausteine und Daten wiederverwenden. Gemeinsame Schritte wie der Login gehören in wiederverwendbare Komponenten, Testdaten in eine einzige Quelle. Vermeiden Sie Abhängigkeiten zwischen Tests.

8. In die Pipeline bringen und pflegen. Automatisierte Tests laufen idealerweise bei jedem Build, wie im Beitrag zu Testautomatisierung in CI/CD-Pipelines beschrieben. Tests ohne Nutzen nehmen Sie laut CT-TAS gezielt aus dem Bestand.

Die sieben Strategie-Elemente aus CT-TAS §1.1.1 eignen sich als Prüfliste, hier mit Beispielen aus einer Bank:

Was braucht die Testumgebung für automatisierte Tests?

Automatisierte Tests brauchen eine stabile, von der Produktion getrennte Testumgebung und Testdaten, die bei jedem Lauf in einem bekannten Zustand sind. Der CTFL-Lehrplan nennt als typische Bestandteile „Platzhalter, Treiber, Simulatoren und Dienst-Virtualisierungen“ (ISTQB CTFL Lehrplan 4.0.2, 2025).

Komplexität hat ihren Preis. Der CT-TAS-Lehrplan warnt, eine überladene Testumgebung könne Stunden kosten, in denen das Team Fehler im Testautomatisierungs-Framework behebt, statt von der Lösung zu profitieren. Die Twelve-Factor-Methode rät, Entwicklung, Staging und Produktion „as similar as possible“ zu halten (The Twelve-Factor App, 2026).

Für Testdaten setzt DORA eine harte Grenze: In Testumgebungen dürfen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten liegen, Ausnahmen nur befristet und genehmigt (Delegierte Verordnung (EU) 2024/1774, Art. 16 Abs. 5 und 6, 2024). Wie Sie Umgebungen stufen und stabil halten, erklärt der Beitrag zur Testumgebung für automatisierte Tests.

Wann rechnet sich Testautomatisierung?

Testautomatisierung rechnet sich, sobald die eingesparte Zeit die investierte Zeit übersteigt. Der ISTQB-Lehrplan CT-TAS v1.0 gibt dafür die Formel „ROI = Savings / Investment“ an, als Quotient in Zeiteinheiten (ISTQB CT-TAS v1.0, 2024). Ab einem Wert über 1,0 ist die Gewinnschwelle überschritten. Ein Projektsatz rechnet Stunden in Geld um.

Abbildung 4: Die ROI-Formel (eigene Darstellung nach ISTQB CT-TAS v1.0)

Das Modell zählt als Einsparung die Zeit für manuelle und automatisierte Läufe, die Zahl der Testfälle und der Durchläufe. Als Investition zählen Einrichtung, Skriptentwicklung, Wartung und der Anteil fehlschlagender Skripte, darum drückt jeder Flaky Test den ROI.

Verbreitete Ratgeber rechnen mit (Nutzen − Kosten) / Kosten; das ISTQB nutzt den einfachen Quotienten. Für kurze Projekte zieht der Lehrplan eine klare Grenze: „If the planned project duration is less than the turning point of the ROI, it is not worth introducing test automation.“ Eine Beispielrechnung mit allen Kennzahlen steht im Beitrag zum ROI der Testautomatisierung.

Stimmen „80 % Einsparung“ und die 1:10:100-Regel?

Für die oft zitierte Einsparung von 80 % durch Testautomatisierung haben wir keine Primärstudie gefunden. Der CT-TAS-Lehrplan hält fest, dass 100 % Automatisierungsabdeckung nicht erreichbar ist (ISTQB CT-TAS v1.0, 2024).

Die 1:10:100-Regel, nach der ein Fehler in jeder späteren Phase zehnmal teurer wird, geht auf ein „IBM Systems Sciences Institute“ zurück. Laurent Bossavit verfolgte die Quelle bis zu internem Schulungsmaterial mit Daten vermutlich von vor 1981 (The Register, 2021). Menzies et al. fanden in 171 Projekten keinen verlässlichen Effekt dieser Art (Menzies et al., 2016). Google beschreibt späte Fehler weiterhin als teurer; die Kostenkurve hängt vom Projekt ab.

Was verlangen DORA und FINMA von Tests in Banken?

DORA und das FINMA-Rundschreiben 2023/1 verlangen von Banken kontrolliert getestete IKT-Änderungen und getrennte Test- und Produktionsumgebungen; DORA fordert dazu jährliche Tests kritischer Systeme und erlaubt in Testumgebungen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten. DORA (Verordnung (EU) 2022/2554) gilt seit dem 17. Januar 2025 für Finanzunternehmen in der EU. Art. 9 Abs. 4 lit. e verlangt, dass IKT-Änderungen kontrolliert getestet, bewertet, genehmigt, umgesetzt und überprüft werden (Verordnung (EU) 2022/2554, 2022).

Für den Testalltag sind fünf Vorgaben aus DORA und der Delegierten Verordnung (EU) 2024/1774 relevant:

• Art. 24 Abs. 6 DORA: mindestens jährlich angemessene Tests aller IKT-Systeme und -Anwendungen, die kritische oder wichtige Funktionen unterstützen.

• Art. 25 Abs. 1 DORA: Mögliche Tests reichen von Quellcode-Reviews über szenariobasierte und Kompatibilitätstests bis zu Performance- und Penetrationstests.

• Art. 16 Abs. 2 RTS 2024/1774: ein Verfahren zum Testen und Genehmigen aller IKT-Systeme vor ihrer Nutzung und nach Wartung.

• Art. 8 Abs. 2 lit. b RTS: Trennung der Produktion von Entwicklungs- und Testumgebungen. Tests in der Produktion nur begründet, befristet und genehmigt.

• Art. 16 Abs. 5 RTS: „in Nichtproduktionsumgebungen dürfen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten gespeichert werden“ (Delegierte Verordnung (EU) 2024/1774, 2024). Abs. 6 lässt Produktionsdaten nur für bestimmte Testanlässe zu, befristet und genehmigt.

In der Schweiz gilt das FINMA-Rundschreiben 2023/1 „Operationelle Risiken und Resilienz – Banken“, in Kraft seit dem 1. Januar 2024 als Ersatz für das RS 2008/21. Es richtet sich an Banken und Wertpapierhäuser, nicht an Versicherungen. Im IKT-Änderungsmanagement verlangt es eine „Trennung zwischen den Umgebungen für die Entwicklung oder das Testen“ und der Produktion sowie Tests der Anforderungen nach ihrer Kritikalität (FINMA-RS 2023/1, Abschnitt Änderungsmanagement, 2022).

Die Pflichten liegen beim Institut: Prozess, Genehmigung und Risikobewertung kann kein Werkzeug übernehmen. Automatisierte Tests helfen beim Nachweis, wenn jeder Lauf mit Version, Umgebung, Daten und Ergebnis protokolliert ist. Prüfen Sie Betriebsmodell, Rechte und Audit-Trail vor dem Kauf.

Wo passt Autemos in die Testautomatisierung?

Autemos ist eine KI-gestützte Software für Testautomatisierung der selementrix GmbH aus Baar (Kanton Zug), die funktionale Tests für Web, Mobile (iOS und Android), APIs (REST und SOAP) und Desktop-Anwendungen automatisiert. Unit-Tests schreiben Entwickler weiterhin in ihren eigenen Frameworks.

• [Visuelle Test-Workflows](/features/test-workflows): Fachbereiche bauen Tests per Drag-and-drop ohne Code, Engineers ergänzen Code-Blöcke oder binden bestehende Playwright-Tests ein.

• AI Recorder: Aus einem Jira-Ticket, einer User Story oder einem Testfall in Klartext entsteht ein ausführbarer Entwurf. Jeder KI-generierte Schritt braucht die Freigabe des Teams, bevor er läuft.

• Export ohne Lock-in: Web-Tests als Playwright-Code (Java oder TypeScript), Mobile-Tests als Appium (Java), synchronisiert mit Git. Die Tests laufen ohne Autemos weiter, was das CTFL-Risiko der Herstellerabhängigkeit adressiert.

• Testdaten pro Umgebung: Datensätze aus CSV, XLSX, JSON oder externen Quellen. Einmal-Daten werden markiert, damit parallele Läufe sie nicht doppelt verwenden.

• Selbstheilende Locator: jede Korrektur dokumentiert und umkehrbar.

• Governance und Anbindung: rollenbasierte Rechte, Audit-Trail, mTLS- und Smartcard-Login, Betrieb vor Ort (OnPrem), Jira/Xray, GitLab, GitHub Actions, Jenkins und Allure-Reports.

Autemos führt keine Last-, Performance-, Sicherheits- oder Penetrationstests durch; die in DORA Art. 25 genannten Performance- und Penetrationstests brauchen andere Werkzeuge. Autemos misst keine Code-Überdeckung, stellt keine Testumgebungen bereit, anonymisiert keine Produktionsdaten und schreibt weder Ihre Teststrategie noch Ihre ROI-Rechnung. Wie KI-Funktionen in den Testprozess passen, beschreibt der Leitfaden zur KI-Testautomatisierung.

Häufig gestellte Fragen

Was kostet die Einführung von Testautomatisierung?

Eine seriöse Pauschalzahl gibt es nicht; die Kosten hängen von Einführung, Skriptentwicklung, Wartung und der Phase mit parallelen manuellen Tests ab. CT-TAS nennt Personal, Hardware und Schulung als Einführungskosten und spricht von „in most cases, significant cost“ (ISTQB CT-TAS v1.0, 2024).

Ersetzt Testautomatisierung manuelles Testen?

Nein, explorative Tests, Usability und fachliche Ermessensentscheidungen bleiben manuell. 80 % der von Rafi et al. befragten Praktiker widersprachen der Vorstellung, automatisierte Tests würden manuelles Testen vollständig ersetzen (Rafi et al., AST, 2012).

Wie viel Prozent der Tests sollte man automatisieren?

Eine feste Quote gibt es nicht, und 100 % Abdeckung durch Automatisierung ist laut CT-TAS-Lehrplan nicht erreichbar. Für die Verteilung nannte Google 70 % Unit-, 20 % Integrations- und 10 % E2E-Tests als erste Schätzung (Google Testing Blog, 2015). Maßgeblich bleiben Ausführungshäufigkeit, Stabilität und ROI je Test.

Welche Rolle spielt KI in der Testautomatisierung?

KI hilft beim Entwerfen und Warten von Tests, und viele Unternehmen erproben das gerade. Im World Quality Report 2025, einer Herstellerumfrage von Capgemini, Sogeti und OpenText unter mehr als 2.000 Führungskräften, gaben 89 % an, GenAI-gestützte Qualitätsprozesse zu pilotieren oder einzusetzen. Nur 15 % hatten den unternehmensweiten Einsatz erreicht (OpenText, WQR 2025, 2025).

Gilt DORA für Schweizer Banken?

DORA gilt für Finanzunternehmen in der EU; Schweizer Banken unterstehen der FINMA und dem Rundschreiben 2023/1. Schweizer Gruppen mit Gesellschaften in der EU sollten prüfen, ob diese Einheiten unter DORA fallen. Inhaltlich überschneiden sich viele Anforderungen: getrennte Testumgebungen, kontrollierte Änderungen und regelmäßige Tests kritischer Funktionen.

Fazit

Testautomatisierung zahlt sich aus, wenn Sie sie als Programm mit Strategie, Pilot und ehrlicher ROI-Rechnung einführen. Beginnen Sie mit Regressionstests, die manuell stabil laufen, und planen Sie die Monate mit parallelen manuellen und automatisierten Tests als Mehrkosten ein. Flaky Tests dulden Sie nicht. Banken trennen nach DORA (EU) und FINMA-RS 2023/1 (Schweiz) Test- und Produktionsumgebungen; unter DORA gehören nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten in Testumgebungen. Prüfen Sie jedes Werkzeug an den acht CTFL-Risiken, vor allem an der Herstellerabhängigkeit. Wenn Sie sehen möchten, wie funktionale Tests in visuellen Workflows mit Playwright-Export in Ihrer Umgebung laufen, vereinbaren Sie ein Gespräch mit dem Autemos-Team.