Warum Testautomatisierung in den meisten Organisationen scheitert

70 % aller Testautomatisierungsinitiativen scheitern an den Erwartungen. George Ukkuru hat über 15 Jahre mehr als 100 Initiativen analysiert und dieses Muster branchenübergreifend dokumentiert. Die Tools sind selten das Problem. Die Architektur fehlt.

Tool kaufen, scheitern, nächstes Tool kaufen

Eine globale Investmentplattform investiert 1.2 Mio. USD in Selenium-basierte Testautomatisierung. Nach 16 Monaten wird das Projekt aufgegeben. Brüchige Selektoren, unkontrollierter Wartungsaufwand, keine Chance, mit Änderungen an der Anwendung Schritt zu halten.

Ein Versicherungsunternehmen rechnet mit USD 340’000 jährlicher Einsparung durch Automatisierung. Tatsächlich entstehen USD 480’000 Wartungskosten pro Jahr. Releases werden 23 % langsamer. Nettoverlust statt Einsparung.

Diese Fälle sind keine Ausnahmen. Das Muster wiederholt sich branchenübergreifend, von Finanzdienstleistern über Pharma bis zur öffentlichen Verwaltung.

Fünf Ursachen, die sich gegenseitig verstärken

Fehlende Teststrategie

Die meisten Organisationen starten mit Automatisierung, bevor eine Teststrategie steht. Automatisiert wird, was manuell am meisten Zeit kostet. Typischerweise GUI-Tests. So entsteht eine invertierte Testpyramide: viele langsame, brüchige End-to-End-Tests, wenig schnelle Unit- und Integrationstests.

Google hat das quantifiziert: Ein Team brauchte über sieben Tage, um eine E2E-Suite von 5 % auf 89 % Pass-Rate zu bringen. Der Milestone wurde um eine Woche verfehlt. Die Tests liefen — aber sie testeten die falschen Dinge auf der falschen Ebene.

Tool-Fixierung

Proprietäre Testtools kosten 50’000 bis 500’000 Euro pro Jahr an Lizenzgebühren. Sie versprechen «Testen ohne Programmierung». Für Demos funktioniert das. Für 10’000 Tests im Produktiveinsatz nicht.

Jedes neue Tool bringt neues Spezialwissen. Teams brauchen Tosca-Expertinnen, UFT-Spezialisten, Ranorex-Kenner — Fachkräfte, die am Markt schwer zu finden sind. Organisationen betreiben durchschnittlich 7.4 Testing-Tools parallel; 75 % verlieren 6 bis 15 Stunden pro Woche durch diesen Wildwuchs.

Flaky Tests zerstören das Vertrauen

Bei Google sind 16 % aller Tests von Flakiness betroffen. 84 % aller Statuswechsel von «bestanden» zu «fehlgeschlagen» gehen auf instabile Tests zurück, nicht auf echte Fehler. Atlassian verliert jährlich über 150’000 Entwicklerstunden durch Reruns.

Wenn Tests zufällig fehlschlagen, ignorieren Teams die Ergebnisse. Google vergleicht den Effekt mit Pilotinnen und Piloten, die Alarme abschalten, weil zu viele Fehlalarme kommen. Ab 1 % Flakiness sinkt der Wert einer Test-Suite signifikant.

Test-Code bekommt weniger Sorgfalt als Produktionscode

Kein Code Review, keine Modularisierung, keine Versionierung. Test-Schulden wachsen schneller als der Nutzen. Sobald die Suite eine bestimmte Grösse erreicht, wird jede Änderung am System zum Risiko: niemand weiss, welche Tests brechen und warum.

Ein Fortune-500-Hersteller investierte USD 890’000 über 18 Monate in 1’200 automatisierte Testszenarien. Gesamtkosten am Ende: USD 2.3 Mio. ROI: minus 180 %. Die Suite wurde zur Wartungslast statt zum Beschleuniger.

Der Capgemini World Quality Report 2023-24 bestätigt das Muster: nur 3 % der Organisationen haben ihre Regression-Suites vollständig in Delivery-Pipelines integriert. Die Hälfte der Tests läuft instabil, und niemand weiss, welche Fehler relevant sind.

QA als Silo

In vielen Organisationen ist Qualitätssicherung eine separate Abteilung. Entwicklung «wirft Code über die Mauer» zur QA. Späte Fehlererkennung, lange Feedback-Zyklen, Schuldzuweisungen statt gemeinsamer Verantwortung.

Die DORA-Reports zeigen den Unterschied: Elite-Performer deployen 973-mal häufiger als Low-Performer. Sie erreichen eine drei Mal niedrigere Change Failure Rate. Der Schlüssel: Testing ist Teil der Entwicklung, kein nachgelagerter Schritt.

Die negative Feedback-Schleife

Diese fünf Ursachen verstärken sich gegenseitig. Fehlende Teststrategie führt zu falschen Tests. Falsche Tests werden instabil. Instabile Tests verlieren das Vertrauen des Teams. Das Team investiert weniger in Testqualität. Test-Schulden wachsen. Jede Änderung wird riskanter. Der Druck steigt, das nächste Tool zu evaluieren.

Martin Fowler zitiert Justin Searls: «Fast kein Team schreibt Tests, die klare Grenzen setzen, schnell laufen und nur aus nützlichen Gründen fehlschlagen.» Das ist kein Tool-Problem. Das ist ein Architektur-Problem.

Was Architektur anders macht

Wer Testautomatisierung als Softwareentwicklung behandelt, behandelt Test-Code mit derselben Disziplin wie Produktionscode. Modularität, Code Review, Versionierung, CI/CD. Kein Sonderstatus für Testcode, keine Ausnahmen bei der Qualität.

Eine durchdachte Testarchitektur adressiert die fünf Ursachen:

Teststrategie statt Tool-Fixierung — die richtige Verteilung über Testebenen, nicht das nächste Tool
Wiederverwendbare Bausteine — Keywords und Libraries, die über Projekte hinweg funktionieren
Stabilität durch Design — API-First statt GUI-Only, deterministische Tests statt Flakiness
Lesbare Tests — Testszenarien, die auch Fachtester und Auditorinnen verstehen
Integriert statt isoliert — Tests als Teil der Entwicklung

Eine grosse deutsche Sozialversicherung hat diesen Weg beschritten: von wenigen manuellen Tests zu über 10’000 automatisierten Tests. Nächtliche Regression über 20 parallele CI/CD-Jobs. Null Euro Lizenzkosten. Neue Teammitglieder produktiv in Tagen statt Wochen. Die Tests dienen gleichzeitig als Dokumentation für Auditorinnen.

Drei Fragen an die eigene Testlandschaft

Können Sie beziffern, wie viel Test-Wartung pro Monat kostet?
Vertraut das Team den Testergebnissen, oder werden fehlgeschlagene Tests routinemässig ignoriert?
Kann ein neues Teammitglied die Tests verstehen, ohne den Autor zu fragen?

Wenn bei mindestens einer Frage Zögern eintritt, lohnt sich ein genauer Blick auf die Testarchitektur.