Wann sich Testautomatisierung rechnet

Die Regel: oft laufen, teurer Fehler

Testautomatisierung ist eine Investition, keine Qualitätsmaßnahme an sich. Ein automatisierter Test spart Geld, wenn er eine Prüfung ersetzt, die sonst immer wieder von Hand läuft, und wenn der gefundene Fehler teurer wäre als der Test selbst. Beide Bedingungen müssen zusammenkommen. Ein Test, der zweimal im Jahr läuft, spart kaum Arbeitszeit. Ein Test für einen Ablauf, dessen Ausfall niemand bemerkt, verhindert keinen teuren Schaden.

Daraus folgt auch, was manuell bleiben sollte: Prüfungen, die selten laufen, Oberflächen, die sich jede Woche ändern, und explorative Tests, bei denen ein Mensch nach Unerwartetem sucht. Wer diese Fälle automatisiert, bezahlt den Einmalaufwand und anschließend die Pflege, ohne nennenswert Zeit zurückzubekommen.

Was in die Rechnung gehört

In Gesprächen mit Entwicklungsleitern sehe ich meist nur zwei Posten: den Aufwand für den Aufbau und die eingesparte Testzeit. Eine ehrliche Rechnung hat vier.

Die ersten drei Posten lassen sich in Stunden rechnen. Den vierten sollte man wenigstens benennen: Was kostet ein Fehler in der Abrechnung, im Login oder in einer Schnittstelle, wenn er einen Monat lang unentdeckt bleibt?

• Einmalaufwand: Framework, Testumgebung, Testdaten, die ersten Tests und die Einbindung in die Pipeline.
• Laufende Pflege: Tests an geänderte Oberflächen anpassen, instabile Tests untersuchen, Testdaten aktuell halten. Dieser Posten wird fast immer unterschätzt.
• Eingesparte Testzeit: die Stunden, die ein manueller Regressionslauf heute bindet, multipliziert mit der Häufigkeit und mit dem Anteil, der sich tatsächlich automatisieren lässt.
• Restrisiko: Fehler, die trotz Automatisierung durchkommen, und Fehler, die ohne Automatisierung beim Kunden landen. Dieser Posten lässt sich selten in Euro beziffern, entscheidet aber oft über den Ausgang.

Eine Break-even-Formel mit Beispiel

Die einfachste Form der Rechnung lässt das Restrisiko außen vor und fragt nur: Nach wie vielen Monaten hat die eingesparte Zeit den Aufbau bezahlt? Break-even in Monaten = Einmalaufwand in Stunden geteilt durch die monatliche Netto-Ersparnis in Stunden. Die Netto-Ersparnis ist: Läufe pro Monat mal Stunden je Lauf mal automatisierbarer Anteil, abzüglich der Pflege pro Monat.

Ein Beispiel mit plausiblen Werten für ein kleines Produktteam. Die Regression läuft viermal im Monat und dauert 16 Stunden, der interne Stundensatz liegt bei 90 €. Die Automatisierung kostet 120 Stunden Aufbau und 6 Stunden Pflege pro Monat, 70 % der Prüfungen lassen sich automatisieren.

Dieselbe Formel zeigt, wann es sich nicht lohnt. Läuft die Regression nur einmal im Monat, sinkt die Netto-Ersparnis auf 11,2 minus 6 = 5,2 Stunden pro Monat. Der Break-even rückt auf rund 23 Monate. In dieser Zeit hat sich die Software so weit verändert, dass ein Teil der Tests ohnehin neu geschrieben werden muss. Die Häufigkeit entscheidet, nicht die Technik.

• Manueller Aufwand heute: 4 × 16 Stunden = 64 Stunden pro Monat, also 5.760 € pro Monat.
• Davon automatisierbar: 70 % von 64 Stunden = 44,8 Stunden pro Monat.
• Netto-Ersparnis: 44,8 Stunden minus 6 Stunden Pflege = 38,8 Stunden pro Monat, also 3.492 € pro Monat.
• Einmalaufwand: 120 Stunden × 90 € = 10.800 €.
• Break-even: 120 Stunden geteilt durch 38,8 Stunden pro Monat = rund 3,1 Monate. Nach zwölf Monaten stehen 465,6 Stunden Netto-Ersparnis (41.904 €) gegen 10.800 € Einmalaufwand.

Die Testpyramide als Kostenhebel

Einmalaufwand und Pflege hängen stark davon ab, auf welcher Ebene getestet wird. Ham Vocke beschreibt auf martinfowler.com die Testpyramide: viele schnelle Unit-Tests als Basis, weniger Integrationstests darüber, wenige Tests über die Oberfläche an der Spitze. Je höher ein Test in der Pyramide sitzt, desto mehr Teile des Systems braucht er und desto langsamer läuft er. Außerdem bricht er häufiger aus Gründen, die nichts mit dem geprüften Verhalten zu tun haben.

Für die Rechnung heißt das: Eine Prüfung, die sich als Unit- oder Integrationstest formulieren lässt, kostet in Aufbau und Pflege einen Bruchteil eines UI-Tests. Viele Teams automatisieren zuerst das, was der manuelle Tester sieht, also die Oberfläche. Günstiger ist oft, die Geschäftslogik darunter abzusichern und nur die wenigen Abläufe über die Oberfläche zu testen, bei denen das Zusammenspiel aller Teile das eigentliche Risiko ist. Der automatisierbare Anteil aus dem Beispiel steigt dadurch nicht, aber die 120 Stunden Aufbau und die 6 Stunden Pflege sinken.

Flaky Tests und Testdaten: die unterschätzten Pflegekosten

Ein Test, der ohne Codeänderung mal grün und mal rot ist, kostet doppelt: Jemand muss das Ergebnis prüfen, und das Team verliert das Vertrauen in die gesamte Suite. Google berichtet im eigenen Testing Blog, dass dort etwa 1,5 % aller Testläufe ein solches instabiles Ergebnis lieferten, bei Millionen von Tests ein erheblicher Aufwand. Die Gegenmaßnahmen sind bekannt: betroffene Tests markieren, isolieren, gezielt wiederholen und die Ursache beheben, meist Zeitabhängigkeiten, geteilte Zustände oder externe Dienste.

Der zweite Pflegetreiber sind Testdaten. Tests, die auf einer gemeinsamen Datenbank mit gewachsenem Inhalt laufen, brechen, sobald jemand diesen Inhalt ändert. Tests, die ihre Daten selbst anlegen und wieder entfernen, sind aufwendiger zu schreiben und deutlich günstiger zu pflegen. Wer die 6 Stunden Pflege aus dem Beispiel halten will, muss beide Punkte von Anfang an mitplanen.

Hotfixes und der Cyber Resilience Act

Bisher ging es um eingesparte Stunden. Es gibt einen zweiten Treiber, der sich nicht in der Formel abbildet: die Zeit zwischen einem gefundenen Fehler und dem ausgelieferten Fix. Wenn jeder Fix den vollen manuellen Regressionslauf braucht, dauert ein Hotfix mindestens so lange wie dieser Lauf, im Beispiel zwei Arbeitstage. Mit automatisierter Absicherung der kritischen Abläufe sind es Stunden.

Für Hersteller von Produkten mit digitalen Elementen wird das zur Pflicht. Die Verordnung (EU) 2024/2847, der Cyber Resilience Act, verlangt in Anhang I, dass Schwachstellen unverzüglich behoben werden, auch durch Sicherheitsupdates. Aktiv ausgenutzte Schwachstellen sind nach Artikel 14 innerhalb von 24 Stunden zu melden. Wer dann erst einen mehrtägigen Testlauf startet, hat ein Problem. Die Fähigkeit, eine kleine Änderung schnell und abgesichert auszuliefern, ist damit kein Komfort mehr, sondern eine Anforderung. Welche Produkte betroffen sind und ab wann, klärt die Rechtsabteilung. Die technische Fähigkeit dazu lässt sich jetzt aufbauen. In der Rechnung gehört sie auf die Seite des Restrisikos, und dort wiegt sie schwer.

Was das für Ihre Entscheidung heißt

Die Rechnung ist kein Argument für oder gegen Automatisierung, sondern ein Filter je Prüfung. Setzen Sie Ihre eigenen Zahlen ein: Wie oft läuft die Regression, und wie lange dauert sie? Welcher Anteil lässt sich mit vertretbarem Aufwand automatisieren? Was kostet ein Fehler in den Abläufen, die dabei herausfallen? Kandidaten mit vielen Läufen und hohem Fehlerrisiko kommen zuerst. Kandidaten mit wenigen Läufen und niedrigem Risiko bleiben manuell, und das ist keine Schwäche.

Wer die Zahlen für die eigene Situation durchspielen möchte, nutzt den Rentabilitätsrechner auf dieser Website. Er rechnet mit derselben Formel wie dieser Artikel und zeigt Break-even und Jahresersparnis für Ihre Werte.