Most enterprise automation suites do not fail because the tests were badly written. They fail because the application changed and the tests did not.

A regression suite built around a stable Oracle EBS instance ages well. The same suite pointed at Fusion Cloud, with quarterly updates arriving whether you want them or not, ages badly. Selectors move. Page structures change. A field that was optional last quarter is mandatory this quarter, and forty tests fail for a reason that has nothing to do with a defect. Teams then spend their sprint triaging false failures. After enough of those sprints, people stop trusting the suite. A red build that is usually wrong is worse than no build at all, because it trains everyone to ignore it.

The Sembi Software Quality Pulse Report put roughly 45% of QA teams in the understaffed category. Those are the same teams being asked to absorb testing volume from AI-generated application code. The maintenance burden was already the constraint. It is now the constraint under load.

Traditional scripting gives you precision and a maintenance bill. You control exactly what the test does, and you own every line of it forever.

AI-assisted creation inverts that. You get coverage quickly, and you give up some control over how the test is constructed. For a regression suite covering a stable business process, that trade is usually worth making. For a complex integration test where the assertion logic matters more than the navigation, it usually is not.

The mistake we see most often is treating this as a binary choice. The teams getting real value run both: AI-generated coverage across the broad, repetitive surface of the application, and hand-built tests for the twenty or thirty flows where a defect would actually hurt.

There is also a quieter risk in generation. A suite that quadruples in size without a traceability model behind it is not four times better covered. It is four times more expensive to maintain, and nobody can tell you which requirement any given test is protecting. Volume is not coverage.

Self-healing gets oversold, so it is worth being precise about what it does.

When a test fails because an element identifier changed, self-healing can find the element by other attributes and continue. That is a genuine reduction in false failures, and on a large Oracle or SAP suite it removes a meaningful amount of weekly triage.

What it cannot do is tell you whether the change was intentional. If a developer removed a field because it should no longer exist, self-healing will route around the gap and report a pass. The test now validates a workflow that no longer matches the requirement, and it does so silently.

Self-healing needs to be visible. Every heal should be logged, reviewed and either accepted into the test or escalated as a change. A self-healing suite that nobody audits drifts away from the application over months, and you find out at the worst possible time.

ERP regression is where enterprise testing gets genuinely hard, for reasons that have little to do with tooling.

A single order-to-cash test touches order management, inventory, pricing, tax, receivables and whatever integration layer connects them. It runs against configured data that varies by legal entity. It depends on approval hierarchies that change when someone leaves the company. When it fails, the cause could sit in any of six modules or in the data setup, and working out which takes functional knowledge, not automation skill.

AI helps with the mechanics: building the flows, keeping them running through UI changes, clustering failures. It does not replace the person who knows that this particular tax configuration behaves differently in the Canadian entity.

For quarterly Fusion updates and SAP transports, the practical target is a regression pack that runs unattended overnight and produces a triaged result by morning. That is achievable. What is not achievable is a suite that also tells you which of the failures matter to the business.

The role is shifting rather than shrinking, and the shift is toward judgement.

Exploratory testing has not been automated and probably will not be, because it depends on curiosity about how a system might be misused. Risk assessment stays human: deciding that a change to revenue recognition needs three weeks of validation while a change to a report layout needs an hour. Test design remains a modelling problem, and models are only as good as the person's understanding of the domain.

There is also a review responsibility that did not exist before. Someone has to check that generated tests assert the right things. An AI-written test that navigates correctly and asserts nothing meaningful will pass forever and protect nothing.