Agentisches Testen löst die vier Probleme, an denen Testautomatisierung seit einem Jahrzehnt scheitert
Testautomatisierung gibt es seit über zwanzig Jahren. Die meisten Enterprise-Teams haben es versucht. Viele haben Frameworks gebaut, Spezialisten eingestellt, Tausende Skripte geschrieben. Und trotzdem geht bei der Mehrheit kein Release ohne erheblichen manuellen Aufwand raus.
Der Grund ist einfach: klassische Testautomatisierung beschleunigt die Ausführung, ignoriert aber die Kostentreiber drumherum. Tests schreiben, Tests pflegen, wenn sich die UI ändert, realistische Daten erzeugen, Ergebnisse interpretieren: all das bleibt manuell, teuer und langsam.
UiPath Test Cloud führt agentisches Testen ein, um genau diese vier Bereiche anzugehen. Jeder Bereich steht für eine Phase im Test-Lifecycle, in der ein KI-Agent Arbeit übernimmt, die bisher menschlichen Aufwand, Domänenwissen und Zeit verlangt hat. Das ist es, was „agentisch“ im Testing-Kontext konkret bedeutet, und warum es für Enterprise-Teams mit SAP, Oracle oder Salesforce relevant ist.
Testdesign hört auf, der Flaschenhals zu sein
Der erste Test ist immer der schwerste. Bevor irgendeine Automatisierung läuft, muss jemand entscheiden, was getestet wird, den Testfall schreiben und ihn so strukturieren, dass das Framework ihn ausführen kann. In SAP-Umgebungen erfordert dies tiefes Wissen über Transaktionsflüsse, Datenabhängigkeiten und Integrationspunkte über Module hinweg.
Die meisten Teams unterschätzen diesen Schritt. Sie kaufen ein Tool, weisen einen Tester zu und erwarten innerhalb weniger Wochen eine automatisierte Abdeckung. Was tatsächlich passiert: Der Tester verbringt Monate damit, Prozesse zu mappen, Fälle zu schreiben und Selektoren zu debuggen. Der Rückstand wächst schneller als das Team automatisieren kann. Nach sechs Monaten liegt die Abdeckung bei 15%, und die Stakeholder beginnen, die Investition zu hinterfragen.
Ein agentischer Ansatz verändert den Ausgangspunkt. Der Agent liest Anforderungen und reale Nutzungsdaten, analysiert, wie User tatsächlich durch das System navigieren, identifiziert die Pfade mit der höchsten Relevanz und erzeugt strukturierte Testdefinitionen, die direkt automatisierbar sind. Er schlägt Testfälle vor, die echtes Nutzerverhalten widerspiegeln und nach Häufigkeit sowie geschäftlicher Kritikalität gewichtet werden.
Menschliche Tester reviewen, passen an und geben frei. Der Unterschied liegt im Startpunkt: ein strukturierter Entwurf, der verfeinert werden kann, statt eines leeren Dokuments und eines Exports aus dem Process-Mining. Die Einstiegshürde sinkt von „stell einen Spezialisten für drei Monate ein“ auf „review, was der Agent diese Woche vorschlägt.“
Die Wirkung ist messbar. EDF Renewables hat das mit der UiPath-Testautomatisierung für SAP demonstriert. Sie erreichten knapp 90% Automatisierungsabdeckung. Ihr Deployment-Zyklus verkürzte sich von zwei bis drei Wochen auf zwei bis drei Stunden. Die Design-Phase, historisch der langsamste Teil jeder Testautomatisierungsinitiative, wurde zur schnellsten. Die Kosten fielen um 70%.
Diese Zahl verdient Aufmerksamkeit: 70% Kostenreduktion, primär getrieben durch den Wegfall des manuellen Designflaschenhalses. Die Tests benötigen weiterhin menschliche Aufsicht. Die Architektur braucht weiterhin eine Teststrategie. Was wegfällt, sind die Monate manueller Arbeit, um Geschäftsprozesse in ausführbare Testfälle zu übersetzen.
Für Teams, die eine S/4HANA-Migration planen, ist das besonders relevant. Migrationstests erfordern die Validierung von Hunderten Geschäftsprozessen über konvertierte Datenbestände hinweg. Diese Tests manuell zu entwerfen, dauert Monate. Ein Agent, der Testfälle aus Prozessdokumentation und Nutzungsanalysen generiert, komprimiert diesen Zeitrahmen auf Wochen.
Wartung ist der Kostenblock, den niemand einplant
Das Muster kennen die meisten Teams: Eine Testsuite läuft sechs Monate lang gut. Dann liefert SAP ein Support Pack. Eine Fiori-Kachel verschiebt sich. Ein Feldlabel ändert sich. Plötzlich schlagen 40% der Tests fehl, und keine einzige der Fehlermeldungen verweist auf einen echten Bug. Es sind Wartungsthemen, die durch die Lücke zwischen dem, was der Test erwartet, und dem, wie die UI jetzt aussieht, verursacht werden.
Wartung ist der größte versteckte Kostenblock in der Testautomatisierung. Über einen Dreijahreszeitraum geben Unternehmen regelmäßig mehr für die Reparatur kaputter Tests aus als für deren Erstellung. Die Investition sieht im ersten Jahr gut aus. Im zweiten Jahr erodiert sie. Im dritten Jahr wird die Testsuite entweder aufgegeben oder an ein Offshore-Team übergeben, dessen Hauptaufgabe es ist, sie am Leben zu halten.
Self-Healing-Agenten adressieren das direkt. Wenn ein UI-Element seine Position, sein Label oder seine Struktur ändert, erkennt der Agent die Änderung, mappt sie auf das korrekte neue Element und repariert den Test automatisch. Kein Ticket. Keine manuelle Untersuchung. Keine Sprint-Kapazität, die für „die Testsuite wieder reparieren“ verloren geht.
Das ist am relevantesten in SAP-Umgebungen, in denen vierteljährliche Updates und Support-Packs garantiert sind. Jedes Update beeinflusst UI-Komponenten, Backend-Logik und Integrationsschichten. Eine Testsuite, die diese Änderungen nicht absorbieren kann, wird zur Belastung: Sie kostet Ressourcen bei der Wartung und vermindert bei jedem weiteren Release das Vertrauen.
Die wirtschaftliche Rechnung ist klar. Wenn Wartung 60% des Testautomatisierungs-Budgets verbraucht (ein übliches Verhältnis in Enterprise-SAP-Landschaften nach dem ersten Jahr) und Self-Healing-Agenten das um die Hälfte reduzieren, fließt die freigewordene Kapazität direkt in den Ausbau der Abdeckung. Das ist der Grund, warum das Tool angeschafft wurde, und der Punkt, den die meisten Teams nie erreichen, weil die Wartung ihre Kapazität auffrisst.
UiPaths Ansatz zum Self-Healing geht über einfache Selektor-Reparatur hinaus. Der Agent versteht den geschäftlichen Kontext des Testschritts. Wenn ein Feld in einer Fiori-App von einem Tab auf einen anderen verschoben wird, findet der Agent das Feld nicht einfach über einen neuen CSS-Selektor. Er versteht, dass dieser Schritt einen Kostenstellenwert in einer Bestellung erfasst, und lokalisiert das Feld auf Grundlage dieser Intention. Dieser Unterschied zählt. Selektor-basiertes Healing bricht bei UI-Umstrukturierungen. Intentionsbasiertes Healing überlebt Redesigns.
Synthetische Testdaten beseitigen die Compliance-Falle
Enterprise-Testing hat ein Datenproblem. Um einen Bestellprozess in SAP zu testen, braucht man realistische Daten: Lieferantenstammsätze, Materialnummern, Preiskonditionen, Freigabehierarchien. Historisch haben Teams das gelöst, indem sie Produktivdaten in Testumgebungen kopiert haben.
Dieser Ansatz scheitert auf zwei Ebenen. Produktivdaten enthalten personenbezogene Daten, Finanzdaten und geschäftssensible Details. Sie in Testsysteme zu kopieren, birgt Compliance-Risiken unter der DSGVO, SOX und den internen Data-Governance-Richtlinien. Zweitens altern Produktivdaten. Testumgebungen erhalten selten frische Kopien, sodass Tests auf Daten basieren, die die tatsächlichen Verhältnisse nicht mehr widerspiegeln. Ein Test, der gegen einen veralteten Lieferantenstamm liefergerichtet ist, beweist wenig Aufschluss darüber, wie sich das System heute verhält.
Agenten, die synthetische Testdaten auf Abruf erzeugen, lösen beide Probleme gleichzeitig. Der Agent versteht den Geschäftsprozess, generiert Daten, die zur geforderten Struktur und zu den Constraints passen, und liefert sie, ohne die Produktivsysteme zu berühren.
Konkret sieht das so aus: Ein Tester muss ein Drei-Wege-Abgleich-Szenario in SAP MM validieren: Bestellung, Wareneingang, Rechnungsprüfung. Mit synthetischer Datengenerierung erstellt der Agent einen vollständigen Datensatz: einen Lieferanten mit gültigen Zahlungsbedingungen, ein Material mit der richtigen Bewertungsklasse, eine Bestellung mit passendem Freigabe-Routing, einen Wareneingang mit korrekten Lagerort-Referenzen und eine übereinstimmende Rechnung. Alles generiert, alles intern konsistent, alles nach dem Testabschluss verwerfbar.
Der Tester überspringt die Datenmaskierung, Anonymisierungs-Pipelines und das Warten auf das Basis-Team für ein Mandanten-Refresh. Die Testdaten existieren genau dann und dort, wo der Tester sie braucht.
Für Unternehmen bei einer S/4HANA-Migration beschleunigt diese Fähigkeit die Testzyklen erheblich. Migrationstests erfordern Hunderte von Datenkombinationen zur Validierung konvertierter Sätze. Synthetisch generierte Daten ermöglichen die parallele Testausführung ohne Datenkonflikte. Fünf Tester können dasselbe Geschäftsprozess-Szenario gleichzeitig durchlaufen, jeweils mit einem eigenen, generierten Datensatz, ohne Kollisionen oder Sperren.
Es gibt hier einen Zweitrundeneffekt, der leicht übersehen wird. Wenn Testdaten synthetisch und zweckmäßig sind, weist jeder Testfehler auf ein echtes Problem im System hin. Die Kategorie „schlechte Daten“ bei Fehlanalysen verschwindet. Triage wird schneller, weil Tester aufhören, zu prüfen, ob der Fehler vom Test, den Daten oder dem System stammt. Die Antwort ist: das System.
Auswertung macht aus Testergebnissen Geschäftsentscheidungen
Ein Testlauf produziert Ergebnisse. In einer typischen Enterprise-Umgebung mit 2.000 automatisierten Tests zeigt ein Nachtlauf vielleicht 1.847 Bestanden, 89 Fehlschläge und 64 Fehler. Das QA-Team öffnet eine Tabelle und beginnt mit der Triage.
Welche der 89 Fehlschläge sind echte Defekte? Welche sind Umgebungsprobleme? Welche sind Datenprobleme? Welche sind durch den Test selbst verursacht? Dieser Triage-Prozess dauert Stunden. In komplexen SAP-Landschaften mit mehreren verbundenen Systemen (ECC, CRM, SRM, BW oder deren S/4HANA-Äquivalente) erfordert die Untersuchung das Prüfen von Logs über Systeme hinweg, den Vergleich von Datenzuständen und das Verständnis des Geschäftsprozesses von Ende zu Ende.
Ein auswertender Agent orchestriert den Testlauf über alle Systeme und liefert ein Urteil pro Geschäftsprozess. Er klassifiziert Fehler, identifiziert Ursachen, wo möglich, und leitet Fehlschläge mit Kontext weiter.
Die Ausgabe ändert sich von „Test XYZ_PO_CREATE_001 fehlgeschlagen bei Schritt 14″ zu „Der Bestellanlageprozess schlägt fehl, weil im Zielsystem der Lieferantenstammsatz die Preiskonditionsart PB00 nicht enthält, vermutlich verursacht durch eine unvollständige Datenmigration im Transportauftrag TR-4712.“
Die erste Aussage erfordert eine Interpretation durch einen Menschen. Die zweite befähigt einen Menschen zur Entscheidung. In dieser Unterscheidung liegt die tatsächliche Zeitersparnis.
Für Release-Manager bedeutet das schnellere Go/No-Go-Entscheidungen. Die Frage verschiebt sich von „Wie viele Tests sind bestanden?“ zu „Welche Geschäftsprozesse sind betroffen und wie hoch ist das Risiko eines Releases?“ Wenn der Agent Urteile auf Geschäftsprozessebene liefert, verschiebt sich die Release-Entscheidung aus der IT-Sprache in die Sprache des Business. Eine Testbestehensquote von 92 % sagt fast nichts aus. „Procure-to-Pay funktioniert. Order-to-Cash hat einen Defekt in Bonitätsprüfung, Schritt 3″ sagt genau das, was gebraucht wird.
Gartner prognostiziert, dass 40% der Enterprise-Anwendungen bis 2026 aufgabenspezifische KI-Agenten nutzen werden. Diese Auswertungsfähigkeit ist der stärkste Beleg für diese Prognose. Ein Agent, der klar macht, welche Geschäftsprozesse gesund sind und welche Risiken sie bergen, spricht mit CFOs und COOs. Testbestehensquoten sprechen nur mit QA-Leitern.
Der Auswertungs-Agent erzeugt auch eine Feedback-Schleife. Muster in Fehlschlägen, etwa ein bestimmter Integrationspunkt zwischen SAP und einem CRM-System, der jedes Quartal bricht, werden im Laufe der Zeit sichtbar. Diese Daten fließen zurück ins Testdesign: Der Agent erhöht die Abdeckung an bekannten brüchigen Stellen und reduziert sie dort, wo die Stabilität bewiesen ist. Der Testaufwand ist proportional zum Risiko, und das System wird mit jedem Zyklus intelligenter.
Die vier Fähigkeiten bilden einen Kreislauf
Diese vier Fähigkeiten sind verbunden. Design fließt in die Wartung ein: gut strukturierte Tests lassen sich leichter heilen, weil der Agent deren Absicht versteht. Synthetische Daten unterstützen die Auswertung: wenn Daten kontrolliert und zweckgebaut sind, zeigen Fehlschläge eher auf echte Defekte. Die Auswertung informiert den nächsten Design-Zyklus: Geschäftsprozesse, die wiederholt fehlschlagen, erhalten automatisch eine höhere Testabdeckung.
UiPath Test Cloud positioniert agentisches Testen als diesen verbundenen Kreislauf. Jeder Agent übernimmt eine bestimmte Phase, und die Plattform orchestriert diese in einen kontinuierlichen Fluss. Die Deloitte-Partnerschaft über die ASCEND-Plattform erweitert das Angebot um große SAP-Transformationsprogramme, bei denen Testvolumen und Komplexität das hinausgehen, was ein manuelles Team bewältigen kann.
Für Enterprise-Teams, die 2026 Testautomatisierung evaluieren, hat sich die Fragestellung verschoben. Vor zehn Jahren diskutierten Teams, ob sie Tests überhaupt automatisieren sollen. Heute lautet die Frage: Welche Teile des Test-Lifecycles können Agenten übernehmen, und welche erfordern weiterhin menschliches Urteilsvermögen?
Auf Basis dessen, was UiPath Test Cloud liefert, ist die Antwort klar. Agenten übernehmen Design, Wartung, Datenerzeugung und -auswertung. Menschen übernehmen die Strategie, die Risikobewertung und die finale Release-Entscheidung. Diese Aufteilung setzt Agenten dort ein, wo Wiederholung und Mustererkennung dominieren, und belässt Menschen dort, wo Kontext und Verantwortlichkeit zählen.
Das ist eine Arbeitsteilung, die Sinn ergibt. Und es ist das erste Mal in zwei Jahrzehnten Testautomatisierung, dass der gesamte Lifecycle, vom Testdesign bis zur Ergebnisinterpretation, eine glaubwürdige Antwort für die Teile hat, die manuell zu automatisieren immer zu teuer waren.
Guide Software-Testing:
Was Testautomatisierung mit Agentic Testing wirklich einspart
Warum 92 % der SAP-Migrationen verspätet fertig werden