Building regression into the S/4HANA release rhythm

The question

Regression testing entered most SAP organisations as a project activity: something you did before a major change, staffed by people borrowed from elsewhere, using a pack assembled for the occasion. That model was reasonable when major changes were years apart.

It fits badly with a continuous release cadence, where change arrives on a schedule the enterprise does not control. The question is no longer how to run a regression cycle. It is what kind of thing a regression suite should be.

What we see in programmes

The rebuild-each-time model has a characteristic failure. Because the pack is assembled under time pressure shortly before it is needed, it is at its least reliable precisely when the stakes are highest. Scripts that have not run for months fail for reasons nobody remembers. The first two days of the cycle are spent working out which failures are real. The scope quietly narrows to what can be made to work in the window available, and the narrowing is not recorded anywhere.

The second failure is subtler and more expensive. Because nobody maintains the suite between releases, its coverage drifts away from the business. Processes change; the suite does not. After two or three cycles, what the suite tests and what the business does have diverged enough that a full pass no longer means very much — but it still reports as a full pass.

Both failures come from the same root: regression treated as an event rather than as something that is kept.

A better way to think about it

The reframe is to treat the regression suite as an asset on the balance sheet of the IT estate, with the properties assets have.

It has an owner. A named person accountable for whether it works, not a team that borrows it when a release approaches.

It has a maintenance cycle. Updated when approved changes land, not when it next fails. This is the difference between a suite that degrades gracefully and one that degrades invisibly.

It has a defined scope that is reviewed. What it covers is written down and revisited — typically once or twice a year — against what the business now actually does.

It produces evidence, not just a result. Each execution leaves behind something that can be examined later, which is what makes it useful for audit, for handover, and for the awkward conversation about what changed.

A pack rebuilt before every release is at its least trustworthy exactly when you need to trust it.

What good looks like

A stable core plus a variable edge. The core is the set of critical business processes that must work in every release, maintained continuously, automated where the four selection criteria hold. The edge is release-specific scope, decided per release from what actually changed. Separating these two makes the planning conversation much simpler, because only the edge is negotiable.

Scope per release driven by the change, not by habit. What has been touched — by SAP, by the SI, by your own team — determines the edge. This requires knowing what changed, which is a discipline in itself and is frequently the missing input.

Execution that fits inside the release window by design. If a full cycle takes longer than the window, the suite will be cut under pressure every time, and the cuts will not be deliberate. Better to design a core that fits and extend it than to design one that does not and improvise.

Triage as a planned activity. Every run produces failures that are not defects. Somebody has to separate them. Planning for that work is the difference between a suite people run and a suite people avoid.

Centralising test cases — manual and automated together, linked to solution processes — makes the maintenance question tractable, because when a process changes you can see what tests it touches. Without that link, maintenance is guesswork and tends not to happen.

Questions leadership should ask

Who owns the regression suite between releases? If the answer is a project, there is no capability.

When did we last review what it covers against what the business does?

Does a full cycle fit in the release window? If not, what gets cut, and who decides?

How much of the last cycle was spent triaging failures that were not defects?

If SAP shipped a release next Tuesday, what would we re-test — and would we be confident in the answer?