On May 19, 2026, Tricentis announced AI-assisted automated test case generation inside SAP Enterprise Continuous Testing (SAP ECT): complete, end-to-end test cases built from natural-language prompts, deployed and scaled through SAP AI Units, with self-healing built in to cut maintenance. For a SAP testing organization that’s spent years scripting test cases by hand, the obvious question is sequencing — do you still start a new SAP testing engagement the old way, by having Test Automation Engineers build out a script library first, or do you start with prompts and let the tooling generate the baseline? We think the answer has flipped, and it’s worth explaining why.
What Tricentis actually announced
The announcement, made in Austin and confirmed via SAP’s Chief Partner Officer Karl Fahrbach, adds AI-assisted, prompt-driven test case generation directly inside SAP ECT — no separate tooling or integration layer required. The stated capabilities: generating complete, end-to-end test cases from natural-language descriptions of a business process; using AI agents to design, build, and optimize test scenarios; deploying and scaling those tests via SAP AI Units; and reducing ongoing maintenance through self-healing tests that adapt when the underlying SAP screens or process steps change. Tricentis cites an average of $5.33 million in annual benefit across organizations using its SAP Application Testing solutions, and points to a case study with Jaguar Land Rover as an example of accelerated SAP testing — both figures from Tricentis’s own reporting, not independently audited.
Why starting with prompts beats starting with a script build-out
The traditional sequence for a new SAP testing engagement puts Test Automation Engineers first: they interview process owners, document test cases, then script and maintain them — often for months before the first meaningful regression suite exists. That sequence made sense when generating a test case was the expensive step. It no longer is.
Starting with prompts inverts the investment order. A process owner or QA lead describes a business process in natural language, and the platform generates a working, executable test case immediately — before any automation engineer has scripted a single step. That changes what the first weeks of an engagement look like: instead of spending automation-engineer time building coverage from zero, you spend it reviewing and correcting what the AI already generated, which is a faster and cheaper way to reach a working baseline. It also means the decision to invest more heavily in automation engineering capacity gets made with actual coverage data in hand, not as an upfront bet.
There’s a second reason this matters specifically for SAP: business processes described in natural language map more directly onto how process owners actually think about their workflows than a scripted test case does. That closes some of the gap between what the business believes it’s testing and what the automation suite actually covers — and that gap, not raw scripting effort, is where a meaningful share of production defects tend to originate.
What „out of the box“ realistically gets you
Our own estimate — not a figure Tricentis publishes, so treat it as a planning assumption rather than a vendor benchmark — is that out-of-the-box coverage from natural-language prompts typically lands in the 40–50% range before any manual tuning, based on how well this kind of generation tends to handle well-documented, happy-path business processes. That’s a meaningful head start, but it’s also a ceiling worth being honest about: prompt-generated tests are strongest on the process steps a business user can articulate clearly, and weaker on the exceptions, edge cases, and negative-path scenarios that experienced testers instinctively probe for. Getting from that 40–50% baseline to production-grade coverage still needs deliberate test design — it’s just design work applied on top of a working baseline instead of from a blank canvas.
Where SeaLights for ABAP fits — later, not first
This is where we’d sequence in Tricentis SeaLights for ABAP, and deliberately not on day one. SeaLights continuously analyzes ABAP and non-code changes and maps them to the tests that actually matter, giving visibility into which of the „millions of ABAP and non-code objects“ in a typical SAP landscape are covered and which aren’t. For a brand-new engagement still building its first prompt-generated baseline, that impact-analysis layer has little to work with yet — it needs an existing body of code changes and tests to map against.
The combination makes more sense once an organization has moved past the initial coverage build-out and into steady-state change management: prompts keep generating and maintaining the test baseline as processes evolve, while SeaLights tracks which ABAP changes are actually exercised by that baseline and flags the ones that aren’t — the same problem SAP ECT alone doesn’t solve, since it’s built around end-to-end process tests rather than code-level change impact. Sequenced that way, SeaLights becomes a targeting layer on top of the coverage the prompt-driven approach already built, rather than a second, parallel testing effort.
Our take
The industry shift here isn’t really „AI writes tests now“ — it’s that the cheapest way to reach a usable testing baseline has changed, and the sequencing of a testing engagement should change with it. For new SAP customers, we’d recommend starting with prompt-driven generation inside SAP ECT to get a working baseline fast, treating the 40–50% initial coverage as a starting point rather than a target, and bringing in SeaLights for ABAP once change velocity becomes the complexity bottleneck. Automation engineers still matter in this model; their work just shifts from building coverage from scratch to closing the gap between the AI-generated baseline and what the business-critical exceptions actually require.
If you’re planning a new SAP testing engagement and want help sequencing prompt-driven generation and SeaLights impact analysis for your own landscape, get in touch — that’s the core of what our Agentic Testing practice does.
