Clean core and test effort

The business case for clean core is often written in architecture language: agility, upgrade-readiness, cloud compliance. Testers can make it concrete. Every object that depends on SAP internals must be retested, and sometimes rebuilt, when SAP changes those internals. Every object that uses released interfaces is protected by a stability contract. The level mix of a system therefore predicts its regression effort.

From level to test effort

This is why Contoso's regression strategy is keyed to the extension register. When the next feature pack stack is planned, Priya filters the register by level: the 300 inherited level D objects and the 2,000 level C objects get targeted tests in the first week; level A and B objects are covered by the process regression that runs anyway. As level C and D counts fall, the targeted part shrinks.

Tests that keep the core clean

• ATC in development and at transport release stops new code from slipping below the agreed level.
• ABAP Unit tests on custom logic, such as the core deposit check, catch regressions every time the code changes, not just at upgrades.
• Contract tests on interfaces check that the released APIs still accept and return what consumers expect.
• Process regression in SAP Cloud ALM, partly automated, proves the end-to-end processes still work for the business.

Putting numbers on it

Contoso's first upgrade estimate after go-live made the link explicit. Priya and Kenji estimated the targeted testing and adaptation for each level C and D object, added the standard process regression, and showed the steering committee what the same upgrade would cost if level C halved and level D in critical processes reached zero. That comparison, not a slogan, is what funded the remediation backlog.

The same logic in every option

The link between clean core and test effort is easiest to see in the public edition, where every extension is level A and SAP upgrades twice a year: customers can absorb that rhythm only because nothing they built depends on internals. A private edition customer chooses its rhythm, but the arithmetic is the same. Each level C or D object adds a fixed slice of analysis, adaptation and testing to every stack and upgrade, for as long as it exists. Over a seven-year maintenance horizon with a stack every six months, a fragile object can be tested a dozen times or more. Remediating it once is usually cheaper, and the architect should show that calculation instead of asserting it.