"Getestet" ist ein Wort, das ein Messproblem versteckt. In einem Status-Meeting bedeutet es eine Spalte in einem Spreadsheet, abgehakt. In einem System, das fünf Jahre über ein halbes Dutzend Services und drei Sprachversionen halten muss, bedeutet es eine Regressionssuite, die auf jedem Schritt vor dem Release läuft und den gestrigen Bug abgefangen hätte, bevor er landete. Der Spalt zwischen diesen beiden Bedeutungen ist, wo der grösste Teil der Software-Kosten lebt - und es ist auch der Spalt, in dem KI gerade den Boden hart verschoben hat.
Was Testen tatsächlich kostet
Zuerst die Budgetrealität. Die Zahlen unten sind weit zitierte Branchen-Bandbreiten (ISTQB, IEEE, Jahrzehnte von Projektumfragen), und sie verschieben sich kaum mit dem Tech-Stack.
- Neue Softwareentwicklung: Testen frisst typischerweise 25% bis 40% des gesamten Projektaufwands. Höher in regulierten oder sicherheitskritischen Domänen.
- Software in aktiver Entwicklung (post-MVP, weiterhin Features): jeder Sprint verbraucht 30% bis 50% seiner Kapazität für Tests, und der Anteil wächst mit der Oberfläche. Jedes neue Feature muss mit allem koexistieren, was bereits ausgeliefert wurde, in jeder Sprachversion, in der das Produkt läuft.
- Software in der Wartung: Testen dominiert. 50% bis 70% des Wartungsaufwands sind Verifikationsarbeit. Das ROI-Ziel ist hier geradeaus: jeder Euro für automatisierte Regression spart ein Vielfaches an Produktions-Vorfallkosten. Ein im Test gefangener Bug kostet typischerweise 10x bis 100x weniger als derselbe Bug in Produktion.
Was sich verändert, ist, was diese Prozente kaufen. Dasselbe 30%-Sprint-Budget kann einen einmaligen manuellen Testdurchlauf kaufen, der am nächsten Morgen vergessen ist, oder eine Regressionssuite, die über fünf Jahre hinweg immer wertvoller wird. Das ist die Wahl.
Der Vermögenswert, nicht das Artefakt
Software hält nicht, weil sie einmal gut gebaut wurde. Sie hält, weil sie auslieferfähig bleibt - Monat für Monat, Jahr für Jahr - ohne kaputtzumachen, was bereits bezahlt wurde. Was diese kumulierende Investition schützt, ist Regression: eine Batterie automatisierter Prüfungen, die auf jedem Schritt vor dem Release läuft - der PR-Check, der Integrations-Build, die Staging-Promotion, das Pre-Prod-Gate - und mit Vertrauen sagt: “Sie haben gerade nicht den Rechnungs-Export, den SSO-Login oder das PDF-Rendering für französischsprachige Kunden zerschossen.”
Ein Test, der einmal lief, in ein Jira-X-Ray-Ticket “Passed” eingetragen wurde und nie wieder lief, ist kein Vermögenswert. Es ist ein Dokumentationsartefakt. Die Kosten sind echt - jemand hat einen Tag investiert. Der kumulierende Wert ist null. Beim nächsten Mal, wenn jemand diesen Codebereich anfasst, muss ein Mensch die Arbeit wiederholen - oder, häufiger, tut es nicht und liefert die Änderung trotzdem aus.
Die einzige Art von Testen, die die Investition schützt, ist die, die ohne Sie weiterläuft.
Hat am Ende jemand in der Zielsprache getestet?
Das andere, was den “Getestet”-Stempel nicht überlebt, ist Lokalisierung. Europäische Software liefert in einen fragmentierten Markt. Eine Schweizer App hat Deutsch-, Französisch- und Italienischsprachige Kunden. Zahlenformate spalten sich zwischen CHF 1'000.50 (Apostroph als Tausendertrennzeichen) und 1.000,50 (Komma als Dezimaltrennzeichen). Datum-Strings wie “01/06/2026” können in zwei Sprachversionen gültig sein und unterschiedliche Tage bedeuten. Steuercodes, Postleitzahl-Regexes, der Unterschied zwischen “Mwst.” und “MwSt.”, der Unterschied zwischen “courriel” und “e-mail” - nichts davon taucht in einem Testplan auf, der von Leuten ausgeführt wird, die die Briefe der Kundschaft nicht lesen.
Eine Testerin, die jeden funktionalen Flow durchläuft, kann trotzdem Software ausliefern, die für die Kundschaft kaputt gerendert ist. Bis jemand es meldet, hat sich der Fix zu einem Hotfix-Release, einer Entschuldigungs-E-Mail und (falls die Kundschaft reguliert ist) zu einer Compliance-Frage aufgebaut.
Lokales Wissen ist ein Test-Vermögenswert. Die meisten Test-Budgets bepreisen es nicht so.
Was KI gerade verändert hat
Lange Zeit sah die Mathematik hinter “Testing an ein grosses Offshore-Team auslagern” stabil aus. Manuelles, exploratives Testen skalierte linear mit Personen, und der Hebel war: mehr Tester einstellen.
Die Mathematik ist gekippt. Eine erfahrene Engineerin, die das Produkt, die Sprachversion und den regulatorischen Rahmen kennt, kann sich heute mit einem LLM-unterstützten Explorations-Tool hinsetzen, ein Feature einmal durchlaufen und diesen Durchlauf in einen deterministischen, wiederholbaren End-to-End-Test überführen, der noch am selben Nachmittag in die Regressionssuite einfliesst. Was eine Woche Testskript-Schreiben war, ist jetzt eine Stunde. Was ein einmaliger manueller Durchlauf war, wird zu einem Vermögenswert, der auf jeder Promotion-Stufe weiterläuft, in jeder Sprache, in der das Produkt ausgeliefert wird.
Wir haben Verifizierungszyklen gesehen, die sich von mehrwöchigen Regressionsdurchläufen auf Suiten zusammendrücken, die in Zehnerminuten auf jedem freigaberelevanten Schritt fertig sind. Teams, die früher monatlich auslieferten, liefern heute wöchentlich oder pro Feature, ohne Coverage zu verlieren. Die 10x bis 100x liegen in der Zeit-von-Änderung-zu-verifiziert-ausliefer-fähig, nicht in der reinen Release-Anzahl - und das ist genau die Kennzahl, die den Verantwortlichen wichtig ist.
Das ist keine “Nutze einen Chatbot zum Tests-Schreiben”-Behauptung. Der interessante Teil ist nicht ein einzelnes Tool. Es ist, dass dieselbe erfahrene Person, die die Sprache der Kundschaft lesen kann, beurteilen kann, ob das neue Feature das richtige zu bauen ist, und die Regressionsstrategie entwerfen kann, jetzt auch in wenigen Stunden ein Test-Asset produzieren kann, das früher ein Remote-Team von zehn Personen brauchte. Der Hebel ist an einer unerwarteten Stelle gewachsen.
Die Dringlichkeit: Entwicklungstempo ohne Testtempo ist Kontrollverlust
Das ist der Teil, den die meisten Organisationen noch nicht einpreisen. KI beschleunigt Entwicklungsteams überall. Dieselbe Engineerin, die früher ein Feature pro Woche auslieferte, refaktoriert heute drei Module und prototypisiert ein viertes in derselben Woche. Dieser Durchsatz kumuliert jedes Quartal.
Wenn die Testfunktion nicht im selben Tempo zulegt, ist das Ergebnis nicht “schnellere Auslieferung”. Es ist Kontrollverlust. Mehr Änderungen fliessen durch dasselbe enge Verifikationstor, das Tor wird zum Engpass oder beginnt übersprungen zu werden, und die Produktion wird stillschweigend zur Testumgebung. Die ersten Symptome sind subtil - ein paar mehr Rollbacks, ein unerklärter Anstieg an kundengemeldeten Defekten, eine Regression, die zwei Sprints lang entwischt, bevor jemand es merkt. Die späteren Symptome sind nicht subtil. Es sind ein Audit-Befund, ein Aufsichtsschreiben oder eine zahlende Kundschaft, die Ihnen sagt, sie vertraue der Software, auf der sie ihren Betrieb aufgebaut hat, nicht mehr.
Organisationen, die ein KI-beschleunigtes Entwicklungsteam mit einem Testprozess von 2018 paaren, drehen - meist ohne es zu merken - das Risiko in jedem Sprint hoch. Die einzige stabile Antwort ist, dass das Testtempo mindestens so schnell wachsen muss wie das Entwicklungstempo. Genau das macht Regressions-Automatisierung jetzt strategisch und nicht mehr taktisch.
Warum das lokale/hybride Modell jetzt besser liefert
Das Offshore-Testing-Modell war eine Beschaffungsentscheidung, keine Qualitätsentscheidung. Es ergab Sinn, als die Test-Arbeitskraft der Engpass war und der Headcount der Hebel. Die Vertragsstruktur - abgerechnet nach Testerstunden - passte zur Form der Arbeit.
Diese Form ist überholt für die neue Ökonomie. Ein Team, das nach Stunden abgerechnet wird, hat keinen eingebauten Grund, zwei Drittel der manuellen Arbeit in Automatisierung zu komprimieren. Jira-X-Ray-Tickets mit “getestet” zu füllen, generiert eine abrechenbare Stunde, sichert aber nicht die langfristige Stabilität eines digitalen Produkts. Eine automatisierte, halbautonome Regressionssuite zu produzieren, würde die Rechnung schrumpfen lassen. Die meisten Teams in dieser Vertragsform produzieren deshalb weiterhin das Artefakt, nicht den Vermögenswert - und sie können nicht nebenbei auch noch diejenigen sein, die merken, dass der deutsche Rechnungskopf “MwSt.” sagt, wo “Mwst.” stehen sollte, weil sie die Sprache der Kundschaft nicht lesen.
Ein kleines lokales oder hybrides Team, das auf Testautomatisierung ausgerichtet ist, funktioniert umgekehrt. Je schneller die Regressionssuite Defekte unbeaufsichtigt fängt, desto eher ist das Team frei, die nächsten Features auszuliefern und ein paar explorative manuelle Tests durchzuführen, um die echten Probleme aufzudecken. Jemand im Team versteht den Geschäftskontext der Kundschaft - einschliesslich ihrer Sprache - und merkt, wenn das Datumsformat den falschen Tag rendert. Die Hebelwirkung aus KI kapitalisiert sich. Die Ressourcen richten sich natürlich am gelieferten Wert und am nachhaltigen Wert des Produkts aus, nicht an den in diesem Sprint protokollierten Testerstunden.
Wenn das die Form von Testprozess ist, die Sie wollen, ist genau das der Auftrag unseres Service QA & Testautomatisierung.
Wohin das Test-Budget tatsächlich fliessen muss
Testen ist keine Phase, die man abschliesst. Es ist ein Posten von 30% bis 70%, der die Lebensdauer der Software begleitet, und die einzige Frage, die sich lohnt, ist die, ob Ihre Ausgabe ein Artefakt oder einen Vermögenswert kauft.
Regression, die unbeaufsichtigt auf jedem Schritt vor dem Release läuft - und die jemand im Team in der Zielsprache lesen kann - ist das, was den Wert des Produkts über fünf Jahre schützt. Alles andere ist Dokumentation.
KI beschleunigt Entwicklungsteams schneller, als die meisten Test-Funktionen mithalten können. Wenn Ihr Testprozess nicht im selben Mass komprimiert hat wie Ihr Entwicklungsdurchsatz, verlieren Sie die Kontrolle, auch wenn die Dashboards noch grün aussehen. Wählen Sie ein Team, dessen Vertrag mit dem langfristigen Bestand der Software aligniert ist, nicht mit den in diesem Sprint protokollierten Stunden.
