Am 19. Mai 2026 kündigte Tricentis die KI-gestützte automatisierte Testfallgenerierung innerhalb von SAP Enterprise Continuous Testing (SAP ECT) an: vollständige End-to-End-Testfälle, die auf der Grundlage von Eingaben in natürlicher Sprache erstellt, über SAP AI Units bereitgestellt und skaliert werden und über eine integrierte Selbstheilungsfunktion verfügen, um den Wartungsaufwand zu reduzieren. Für eine SAP-Testorganisation, die jahrelang Testfälle manuell skriptet hat, stellt sich natürlich die Frage nach der Vorgehensweise: Beginnt man ein neues SAP-Testprojekt weiterhin auf die altbewährte Weise, indem Testautomatisierungsingenieure zunächst eine Skriptbibliothek aufbauen, oder beginnt man mit Eingabeaufforderungen und lässt das Tool die Basis generieren? Wir glauben, dass sich die Antwort umgekehrt hat, und es lohnt sich, zu erklären, warum.
Was Tricentis tatsächlich angekündigt hat
Die Ankündigung, die in Austin erfolgte und von Karl Fahrbach, Chief Partner Officer bei SAP, bestätigt wurde, sieht die Einführung einer KI-gestützten, promptgesteuerten Testfallgenerierung direkt in SAP ECT vor – ohne dass separate Tools oder eine Integrationsschicht erforderlich sind. Die angegebenen Funktionen umfassen: die Generierung vollständiger, durchgängiger Testfälle aus Beschreibungen eines Geschäftsprozesses in natürlicher Sprache; den Einsatz von KI-Agenten zum Entwerfen, Erstellen und Optimieren von Testszenarien; die Bereitstellung und Skalierung dieser Tests über SAP AI Units; sowie die Reduzierung des laufenden Wartungsaufwands durch selbstheilende Tests, die sich anpassen, wenn sich die zugrunde liegenden SAP-Bildschirme oder Prozessschritte ändern. Tricentis gibt einen durchschnittlichen jährlichen Nutzen von 5,33 Millionen US-Dollar für Unternehmen an, die seine SAP-Anwendungstestlösungen nutzen, und verweist auf eine Fallstudie mit Jaguar Land Rover als Beispiel für beschleunigte SAP-Tests – beide Zahlen stammen aus Tricentis’ eigener Berichterstattung und wurden nicht unabhängig geprüft.
Warum es besser ist, mit Prompts zu beginnen, als gleich mit der Ausarbeitung eines Drehbuchs
Bei einem neuen SAP-Testprojekt stehen traditionell die Testautomatisierungsingenieure an erster Stelle: Sie befragen die Prozessverantwortlichen, dokumentieren Testfälle, erstellen dann Skripte dafür und pflegen diese – oft über Monate hinweg, bevor die erste aussagekräftige Regressionssuite vorliegt. Diese Vorgehensweise war sinnvoll, als die Erstellung von Testfällen noch der aufwendigste Schritt war. Das ist heute nicht mehr der Fall.
Der Einsatz von Prompts kehrt die Reihenfolge der Investitionen um. Ein Prozessverantwortlicher oder QA-Leiter beschreibt einen Geschäftsprozess in natürlicher Sprache, und die Plattform generiert sofort einen funktionierenden, ausführbaren Testfall – noch bevor ein Automatisierungsingenieur auch nur einen einzigen Schritt programmiert hat. Das verändert den Ablauf der ersten Wochen eines Projekts: Anstatt die Zeit der Automatisierungsingenieure dafür zu verwenden, die Testabdeckung von Grund auf aufzubauen, wird diese Zeit nun dafür genutzt, das bereits von der KI Generierte zu überprüfen und zu korrigieren – ein schnellerer und kostengünstigerer Weg, um eine funktionierende Ausgangsbasis zu erreichen. Es bedeutet auch, dass die Entscheidung, stärker in die Kapazitäten der Automatisierungsentwicklung zu investieren, auf der Grundlage tatsächlicher Abdeckungsdaten getroffen wird und nicht als Spekulation im Voraus.
Es gibt noch einen zweiten Grund, warum dies gerade für SAP von Bedeutung ist: In natürlicher Sprache beschriebene Geschäftsprozesse spiegeln die tatsächliche Denkweise der Prozessverantwortlichen hinsichtlich ihrer Arbeitsabläufe direkter wider als ein skriptbasierter Testfall. Dadurch wird die Kluft zwischen dem, was das Unternehmen zu testen glaubt, und dem, was die Automatisierungssuite tatsächlich abdeckt, teilweise geschlossen – und genau in dieser Kluft, nicht im reinen Skriptierungsaufwand, liegt häufig der Ursprung eines erheblichen Teils der Produktionsfehler.
Was man realistisch gesehen „direkt aus der Verpackung“ bekommt
Nach unserer eigenen Schätzung – es handelt sich hierbei nicht um eine von Tricentis veröffentlichte Zahl, betrachten Sie sie daher eher als Planungsannahme denn als Anbieter-Benchmark – liegt die Abdeckung durch sofort einsatzbereite, auf natürlicher Sprache basierende Eingabeaufforderungen in der Regel im Bereich von 40–50 %, bevor eine manuelle Feinabstimmung erfolgt. Diese Schätzung basiert darauf, wie gut diese Art der Generierung in der Regel gut dokumentierte Geschäftsprozesse im „Happy Path“ bewältigt. Das ist ein bedeutender Vorsprung, aber auch eine Obergrenze, zu der man ehrlich sein sollte: Prompt-generierte Tests sind am stärksten bei den Prozessschritten, die ein Geschäftsanwender klar formulieren kann, und schwächer bei den Ausnahmen, Randfällen und Negativszenarien, die erfahrene Tester instinktiv untersuchen. Um von dieser 40–50-%-Grundlage zu einer produktionsreifen Abdeckung zu gelangen, bedarf es nach wie vor eines durchdachten Testdesigns – es handelt sich lediglich um Designarbeit, die auf einer funktionierenden Grundlage aufbaut, anstatt bei Null anzufangen.
Wo SeaLights für ABAP zum Einsatz kommt – später, nicht von Anfang an
An dieser Stelle würden wir Tricentis SeaLights für ABAP einsetzen – allerdings bewusst nicht gleich am ersten Tag. SeaLights analysiert kontinuierlich Änderungen an ABAP- und Nicht-Code-Objekten und ordnet sie den tatsächlich relevanten Tests zu. So lässt sich nachvollziehen, welche der „Millionen von ABAP- und Nicht-Code-Objekten“ in einer typischen SAP-Landschaft abgedeckt sind und welche nicht. Bei einem brandneuen Projekt, das gerade erst seine erste, automatisch generierte Baseline aufbaut, hat diese Ebene der Auswirkungsanalyse noch wenig Material, mit dem sie arbeiten kann – sie benötigt einen bestehenden Bestand an Codeänderungen und Tests, mit denen sie Abgleiche vornehmen kann.
Diese Kombination ist sinnvoller, sobald ein Unternehmen die anfängliche Erweiterung der Testabdeckung hinter sich gelassen hat und in eine Phase des stabilen Änderungsmanagements übergegangen ist: Prompts generieren und pflegen die Testbasis kontinuierlich, während sich die Prozesse weiterentwickeln, während SeaLights nachverfolgt, welche ABAP-Änderungen tatsächlich von dieser Basis abgedeckt werden, und diejenigen kennzeichnet, die nicht abgedeckt sind – genau das Problem, das SAP ECT allein nicht löst, da es auf End-to-End-Prozesstests basiert und nicht auf den Auswirkungen von Änderungen auf Code-Ebene. In dieser Abfolge wird SeaLights zu einer Zielausrichtungsschicht, die auf der durch den Prompt-gesteuerten Ansatz bereits aufgebauten Testabdeckung aufsetzt, anstatt einen zweiten, parallelen Testaufwand darzustellen.
Unsere Meinung
Der Wandel in der Branche besteht hier nicht wirklich darin, dass „KI nun Tests schreibt“ – vielmehr hat sich der kostengünstigste Weg zu einer brauchbaren Test-Baseline geändert, und die Abfolge eines Testprojekts sollte sich entsprechend anpassen. Neuen SAP-Kunden empfehlen wir, zunächst mit der promptgesteuerten Generierung in SAP ECT zu beginnen, um schnell eine funktionsfähige Basis zu erhalten, die anfängliche Abdeckung von 40–50 % eher als Ausgangspunkt denn als Ziel zu betrachten und SeaLights für ABAP einzusetzen, sobald die Änderungsgeschwindigkeit zum Komplexitätsengpass wird. Automatisierungsingenieure spielen in diesem Modell nach wie vor eine wichtige Rolle; ihre Aufgabe verlagert sich lediglich vom Aufbau der Testabdeckung von Grund auf hin zur Schließung der Lücke zwischen der KI-generierten Basis und den tatsächlichen Anforderungen der geschäftskritischen Ausnahmen.
Wenn Sie ein neues SAP-Testprojekt planen und Unterstützung bei der Abfolge von promptgesteuerter Generierung und SeaLights-Auswirkungsanalyse für Ihre eigene Landschaft benötigen, melden Sie sich bei uns – genau das ist der Kernbereich unserer Agentic-Testing-Praxis.
