·

9 min

ROI der Testautomatisierung berechnen: Formel, Kostenfaktoren und ein ehrlicher Business Case

Roman Kirchmeier - Autemos

Roman Kirchmeier - Autemos

Controllerin und QA-Lead prüfen am Laptop ein Diagramm mit zwei sich kreuzenden Kostenkurven, daneben ein Taschenrechner

Den ROI der Testautomatisierung berechnen Sie nach dem ISTQB-Lehrplan CT-TAS als Quotient: eingesparte manuelle Testzeit geteilt durch die investierte Zeit für Aufbau, Skripte, Wartung und Ausführung. Liegt der Wert über 1, hat sich die Automatisierung bezahlt gemacht. Wann das eintritt, hängt an zwei Größen: wie viel manuelles Testen Sie tatsächlich ersetzen und wie viel Wartung Ihre Skripte brauchen. Eine peer-reviewte Industriestudie errechnete für Saab rund 180 Wochen bis zum Break-even (Alégroth et al., 2016). Kurze Projekte rechnen sich oft nicht. Wo diese Rechnung in die Einführung insgesamt passt, beschreibt der Leitfaden zur Testautomatisierung.

Kurz gefasst: Der ISTQB-Lehrplan CT-TAS (2024) definiert ROI = Savings / Investment, gemessen in Zeit. Einsparungen sind ersetzte manuelle Testläufe, Investitionen sind Aufbau, Skriptentwicklung, Wartung und Ausführung. Über 1 ist die Investition zurückverdient. Wartungszeit und Fehlquote verschieben den Break-even am stärksten. Herstellerstudien mit über 300 % ROI ersetzen keine eigene Rechnung.

Abbildung 1: Die ROI-Formel nach ISTQB CT-TAS (2024)

Wie berechnet man den ROI der Testautomatisierung?

Der ISTQB-Lehrplan Certified Tester Test Automation Strategy (CT-TAS v1.0, Mai 2024) definiert den ROI der Testautomatisierung kurz als „ROI = Savings / Investment“ (ISTQB CT-TAS, 2024). Das Ergebnis ist eine Quote. Bei 1,0 gleichen sich Einsparung und Investition aus, über 1,0 hat sich die Automatisierung bezahlt gemacht, darunter noch nicht.

Im Controlling ist eine andere Form üblich: ROI = (Nutzen − Kosten) / Kosten. Sie liefert einen Prozentwert, bei dem 0 % den Break-even markiert. Beide Formeln sind korrekt und messen dasselbe auf verschiedenen Skalen: Eine CT-TAS-Quote von 1,5 entspricht +50 % in der Finanzform.

CT-TAS rechnet in Stunden und erst danach über einen Projektsatz in Geld. Beide Seiten der Formel brauchen dieselbe Einheit: Rechnen Sie Lizenzgebühren in Stunden um oder alle Stunden in Franken.

Welche Kennzahlen gehören in die ROI-Rechnung?

CT-TAS nennt vier Kennzahlen für die Einsparungsseite und acht für die Investitionsseite, darunter den Prozentsatz fehlschlagender automatisierter Skripte (im Folgenden: Fehlquote) und die durchschnittliche Wartungszeit pro Skript.

Seite der Formel

Kennzahl nach CT-TAS

Woher der Wert kommt

Einsparung

Zeit für eine manuelle Testdurchführung

Zeiterfassung, Testmanagement

Einsparung

Zeit für die automatisierte Durchführung

Pipeline-Logs

Einsparung

Anzahl Testfälle

Regressionssuite

Einsparung

Anzahl Testläufe

Release- und Sprintplan

Investition

Setup-Zeit (Framework, Pipeline, Schulung)

Projektplan, Pilot

Investition

Durchschnittliche Entwicklungszeit pro Skript

Pilot

Investition

Anzahl Skripte

Automatisierungs-Backlog

Investition

Durchschnittliche Wartungszeit pro Skript

Pilot, später Tickets

Investition

Automatisierte Laufzeit

Pipeline-Logs

Investition

Prozentsatz fehlschlagender automatisierter Skripte

Testreports

Investition

Anzahl Testfälle und Anzahl Läufe

wie oben

Laut Lehrplan senkt die Testpyramide die Ausführungszeit und verbessert den ROI. Welche Fälle überhaupt in die Rechnung gehören, klärt die Auswahl der Tests, die sich zum Automatisieren eignen.

Welche Schritte führen zu einer belastbaren ROI-Rechnung?

Eine belastbare Rechnung entsteht in sechs Schritten, vom gemessenen manuellen Aufwand bis zur Überprüfung nach einigen Sprints. CT-TAS empfiehlt dafür einen Pilot: „The use of a pilot project helps determine the tools and viability of selected technologies“ (ISTQB CT-TAS, 2024). Der Pilot liefert die Werte, die Sie sonst raten müssten.

Abbildung 2: Sechs Schritte zu einer belastbaren ROI-Rechnung

  1. Manuellen Aufwand messen. Erfassen Sie für die Regressionssuite die Minuten pro Testfall und die Zahl der Läufe pro Jahr. Nehmen Sie Werte aus Zeiterfassung oder Testmanagement, keine Erinnerungswerte.

  2. Kandidaten auswählen. Starten Sie mit Regressionstests, die CT-TAS als einfachsten Einstieg nennt. Prüfen Sie vorher, ob der manuelle Test stabil läuft.

  3. Pilot automatisieren. Automatisieren Sie 10 bis 20 repräsentative Fälle und messen Sie Setup-Zeit und Entwicklungszeit pro Skript.

  4. Wartung und Fehlquote beobachten. Notieren Sie über mehrere Läufe, wie viele Skripte fehlschlagen und wie lange Analyse und Reparatur dauern.

  5. Hochrechnen und Break-even bestimmen. Kumulieren Sie Einsparung und Investition pro Lauf und suchen Sie den Lauf, an dem die Quote 1,0 erreicht. Vergleichen Sie ihn mit der geplanten Projektdauer.

  6. Nach N Sprints überprüfen. Ersetzen Sie die Pilotwerte nach etwa sechs Sprints durch echte Daten und rechnen Sie neu.

Die Annahmen dieser Rechnung gehören in Ihre Teststrategie mit Zielen und Messgrößen.

Wie sieht eine Beispielrechnung aus?

Eine Regressionssuite mit 200 Testfällen und monatlichem Release erreicht in dieser illustrativen Rechnung den Break-even beim 15. Lauf. Alle Stundenwerte sind Annahmen nach dem Zeitmodell aus CT-TAS, keine Messwerte aus einem Projekt. Ersetzen Sie jede Zeile durch Ihre eigenen Pilotdaten.

Abbildung 3: Beispielrechnung mit illustrativen Annahmen, Break-even beim 15. Lauf

Annahme (Beispiel)

Wert

Testfälle in der Regressionssuite

200

Manuelle Zeit pro Testfall

30 min (100 h pro Regressionslauf)

Läufe pro Jahr

12

Setup: Framework, Pipeline, Schulung

160 h

Entwicklung pro Skript

3 h (600 h gesamt)

Fehlschlagende Skripte pro Lauf

15 % (30 Skripte)

Analyse und Wartung pro fehlschlagendem Skript

45 min (22,5 h pro Lauf)

Betreuung des automatisierten Laufs

2 h pro Lauf

Parallelbetrieb, manuell weiter getestet

erste 3 Läufe

Ergebnis (Beispiel)

Einsparung

Investition

CT-TAS-Quote

Finanzform

Nach 12 Läufen (Jahr 1)

900 h

1’054 h

0,85

−15 %

Nach 15 Läufen

1’200 h

1’128 h

1,06

+6 %

Nach 24 Läufen (Jahr 2)

2’100 h

1’348 h

1,56

+56 %

Bei monatlichem Release sind das 15 Monate. Ein Projekt mit zwölf Monaten Restlaufzeit würde die Investition nicht zurückverdienen. Steigt die Fehlquote von 15 auf 30 %, rückt der Break-even auf den 20. Lauf. Bei 5 % wäre er schon beim 12. Lauf erreicht.

Für Franken brauchen Sie einen Stundensatz. Die SwissICT-Salärumfrage 2025 nennt einen Medianlohn von CHF 130’060 auf Senior-Stufe (itreseller, 2025). Das BFS weist für die IT-Branche einen Median von 9’412 Franken pro Monat aus (LSE 2022, via Netzwoche, 2024).

Mit angenommenen 20 % Arbeitgeberkosten und angenommenen 1’800 Arbeitsstunden pro Jahr ergibt der SwissICT-Senior-Median, hier als Annahme für eine erfahrene Testfachkraft, rund CHF 87 pro Stunde. Das Beispiel kostet damit im ersten Jahr rund CHF 91’700 bei CHF 78’300 Einsparung. Die Quote bleibt bei 0,85. Lizenzkosten kämen in Franken direkt auf die Investitionsseite.

Wann erreicht Testautomatisierung den Break-even?

Testautomatisierung erreicht den Break-even, sobald die kumulierten Einsparungen die kumulierte Investition übersteigen, und das kann Jahre dauern. In einer peer-reviewten Studie zu Visual GUI Testing lag der Break-even für ein modelliertes Projekt mit 20 % Testanteil bei rund 45 Wochen, bei Saab mit rund 7 % manuellem Testaufwand bei rund 180 Wochen (Alégroth et al., 2016).

Abbildung 4: Errechneter Break-even in Wochen nach Alégroth et al. (2016)

Mit seltener Big-Bang-Wartung stieg der Wert bei Saab auf rund 532 Wochen, gut zehn Jahre. Die Autoren folgern: Je weniger Zeit ein Unternehmen heute mit manuellem Testen verbringt, desto länger dauert der Weg zum positiven ROI. Das ist eine einzelne Industriestudie mit GUI-Tests bei Siemens und Saab. Übertragen Sie die Wochen nicht eins zu eins auf Ihr Projekt.

CT-TAS zieht daraus eine unbequeme Konsequenz: „If the planned project duration is less than the turning point of the ROI, it is not worth introducing test automation“ (ISTQB CT-TAS, 2024).

Warum steigen die Kosten in der Übergangsphase?

In der Übergangsphase steigen die Kosten: Manuelle und automatisierte Tests laufen eine Zeit lang parallel. CT-TAS schreibt dazu: „the project should expect increased costs as both manual testing and automated testing take place simultaneously“. Planen Sie diese Phase als eigene Zeile ein, wie die drei Parallel-Läufe im Beispiel oben.

Der Lehrplan warnt davor, einen fehlerhaften manuellen Regressionstest zu automatisieren, bevor die Ursache geklärt ist. Klären Sie solche Fälle vor dem Pilot.

Warum bestimmt die Wartung den ROI?

Wartungszeit pro Skript entscheidet über den Break-even: Sie fällt nach dem Aufbau bei jedem Lauf neu an und lag in einer Industriestudie zwischen rund 23 Minuten (bester Fall) und 110 Minuten (vernachlässigte Suite) pro Skript. Ein manueller Testfall dauerte 29 Minuten (Alégroth et al., 2016). Ihr Befund: „frequent maintenance is less costly than infrequent, big bang maintenance“.

Instabile Tests treiben die Fehlquote nach oben. Bei Google meldeten rund 1,5 % aller Testläufe ein instabiles („flaky“) Ergebnis, und fast 16 % der Tests zeigten eine gewisse Instabilität (Google Testing Blog, 2016). Ein Jahr später waren 14 % der großen Tests instabil, bei den kleinen 0,5 % (Google Testing Blog, 2017).

Jeder dieser Fehlschläge kostet Analysezeit, bis klar ist, ob ein echter Fehlerzustand vorliegt. Konkrete Hebel zur Senkung der Wartungszeit beschreibt der Beitrag Testwartung mit KI reduzieren.

Wo setzt Autemos in der Rechnung an?

Autemos ist eine Software für KI-gestützte Testautomatisierung, die funktionale Tests für Web, Mobile, API und Desktop automatisiert. In der ROI-Rechnung wirkt sie auf eine CT-TAS-Kennzahl: die durchschnittliche Wartungszeit pro Skript. Self-Healing-Locators passen geänderte Element-Locators an, jede Heilung wird dokumentiert und lässt sich zurücknehmen. Die Technik dahinter erklärt der Beitrag zu selbstheilenden Locators.

Eine Ersparniszahl nennen wir dafür bewusst nicht, messen Sie den Effekt in Ihrem Pilot. Der zweite Hebel betrifft die Ausstiegskosten: Autemos exportiert Web-Tests als Playwright-Code (Java oder TypeScript) und Mobile-Tests als Appium (Java), Git-synchronisiert. Die Tests laufen ohne Autemos weiter. Wie sich Werkzeuge bei Lizenz und Lock-in unterscheiden, zeigt der Vergleich von Testautomatisierungs-Tools. Ihren ROI berechnet Autemos nicht für Sie.

Welche ROI-Zahlen gehören nicht in Ihren Business Case?

Zwei oft zitierte Zahlenquellen halten einer Prüfung nicht stand: die „1:10:100-Regel“ zu Fehlerkosten und Auftragsstudien von Herstellern mit dreistelligen ROI-Prozenten.

Stimmt die 1:10:100-Regel?

Für die 1:10:100-Regel gibt es keinen belastbaren empirischen Beleg. Menzies et al. prüften den „delayed issue effect“ in 171 Projekten und schreiben: „We found no evidence for the delayed issue effect“ (Menzies et al., 2016). Das oft zitierte „IBM Systems Sciences Institute“ war laut Recherche von Laurent Bossavit ein internes Schulungsprogramm (The Register, 2021).

Späte Fehler können im Einzelfall teuer sein, etwa ein Produktionsvorfall im Zahlungsverkehr einer Bank. Einen festen Multiplikator gibt die Evidenz nicht her. Rechnen Sie mit Ihren eigenen Incident-Kosten, wenn Sie vermiedene Fehler in den Business Case aufnehmen.

Was taugt eine Forrester-TEI-Studie mit 336 % ROI?

Total-Economic-Impact-Studien (TEI) von Forrester Consulting sind Auftragsstudien eines Herstellers. Eine Studie zu Tricentis Tosca vom August 2026 nennt 336 % ROI und 8 Monate Payback, gestützt auf fünf Entscheider; die Seite vermerkt: „This study is commissioned by Tricentis“ (Forrester TEI, 2026).

TEI-Studien rechnen ein zusammengesetztes Modellunternehmen aus wenigen Kundeninterviews. Die Tosca-Seite beschrieb dieses Unternehmen im Oktober 2026 einmal mit 40 Millionen und einmal mit 40’000 Mitarbeitenden. Für Ihren Business Case taugen solche Werte nicht, das gilt für jeden Hersteller.

Welchen Nutzen erfasst die ROI-Formel nicht?

Die CT-TAS-Formel erfasst eingesparte Zeit; schnellere Rückmeldung und stabilere Releases fehlen darin. Das Forschungsprogramm DORA (dora.dev) von Google, nicht die gleichnamige EU-Verordnung, schreibt: „Manual regression testing is time-consuming to execute and expensive to perform, which makes it a bottleneck in the process“ (DORA, o. J.).

Laut dora.dev verbessert Testautomatisierung die Stabilität der Software, senkt Burnout im Team und macht Deployments weniger mühsam. Führen Sie diese Effekte als eigene, qualitative Zeile neben der Quote. Mögliche Posten:

  • Feedbackzeit pro Merge-Request (Zielwert laut dora.dev: unter zehn Minuten)

  • Zahl der Produktionsvorfälle, die auf Regressionen zurückgehen

  • Freie Zeit der Tester für neue und tiefere Tests, ein Nutzen, den der ISTQB-Lehrplan CTFL 4.0 nennt

  • Häufigere Releases ohne zusätzlichen manuellen Regressionsaufwand

Häufig gestellte Fragen

Was ist der ROI der Testautomatisierung?

Der ROI der Testautomatisierung ist eine Kennzahl, die eingesparte manuelle Testzeit ins Verhältnis zur Investition in Aufbau, Skripte, Wartung und Ausführung setzt. Der ISTQB-Lehrplan CT-TAS definiert ihn als „ROI = Savings / Investment“. Ein Wert über 1 bedeutet, dass sich die Automatisierung bezahlt gemacht hat.

Ab wie vielen Testläufen lohnt sich Automatisierung?

Eine allgemeingültige Zahl gibt es nicht; der Break-even hängt von Wartung, Fehlquote und ersetztem manuellem Aufwand ab. In der illustrativen Beispielrechnung oben liegt er je nach Fehlquote zwischen dem 12. und 20. Lauf. Die Saab-Fallstudie von Alégroth et al. (2016) kam auf rund 180 Wochen.

Welche Tests rechnen sich am schnellsten?

Häufig laufende, stabile Regressionstests rechnen sich am schnellsten, CT-TAS nennt sie den einfachsten Einstieg. Tests mit viel menschlicher Prüfung, etwa die Kreditantragsprüfung aus dem Lehrplan-Beispiel, bleiben besser manuell. Die Kriterien stehen in unserer Checkliste, welche Tests Sie automatisieren sollten.

Garantiert ein neues Testwerkzeug einen positiven ROI?

Ein neues Werkzeug garantiert keinen positiven ROI. Der ISTQB-Lehrplan CTFL 4.0.2 hält fest: „Die bloße Anschaffung eines Werkzeugs ist keine Erfolgsgarantie“ (GTB, 2025). Unrealistische Erwartungen und falsch geschätzte Wartungskosten führt er ausdrücklich als Risiken auf.

Wie oft sollte man den ROI neu berechnen?

Rechnen Sie den ROI nach dem Pilot und danach etwa alle sechs Sprints neu. Ersetzen Sie dabei Annahmen durch gemessene Werte, vor allem Wartungszeit pro Skript und Fehlquote.

Fazit

Der ROI der Testautomatisierung ist eine Quote aus eingesparter und investierter Zeit, und er wird erst nach einer Weile positiv. Rechnen Sie mit der CT-TAS-Formel, messen Sie die Werte im Pilot und planen Sie den Parallelbetrieb als Kosten ein. Prüfen Sie den Break-even gegen die Projektdauer: Liegt er dahinter, lassen Sie die Automatisierung weg.

Wartungszeit pro Skript und Fehlquote bewegen das Ergebnis am stärksten. Erfassen Sie beide ab dem ersten Lauf im Reporting. Faktor-100-Regeln und Auftragsstudien bleiben aus der Rechnung draußen. Sie möchten prüfen, wie Self-Healing und Code-Export die Wartungs- und Ausstiegskosten in Ihrem Pilot verändern? Sprechen Sie mit dem Autemos-Team.

Autemos erleben. In nur 30 Minuten.

Überzeuge dich selbst und erlebe, wie einfach, flexibel und kontrolliert moderne Testautomatisierung heute sein kann.

Social Connect

© 2026 Autemos. Ein Produkt der selementrix GmbH.

Autemos erleben.
In nur 30 Minuten.

Überzeuge dich selbst und erlebe, wie einfach, flexibel und kontrolliert moderne Testautomatisierung heute sein kann.

Social Connect

© 2026 Autemos. Ein Produkt der selementrix GmbH.

Autemos erleben.
In nur 30 Minuten.

Überzeuge dich selbst und erlebe, wie einfach, flexibel und kontrolliert moderne Testautomatisierung heute sein kann.

Social Connect

© 2026 Autemos. Ein Produkt der selementrix GmbH.