Why regression dominates SAP run

Go-live is not the end of testing. It is the start of a different kind. Contoso Motor Co. is now live on SAP S/4HANA 2025 in a private cloud, and the project team has handed over to a run organization. From this point on, most of the testing effort Contoso spends will not go into new features. It will go into one question asked again and again: does everything that worked yesterday still work today? That question is regression testing, and in the run phase of an SAP system it is the dominant test activity. The reason is simple: an SAP system never stops changing. SAP delivers new software, the business asks for new configuration, developers fix and extend custom code, and the platform underneath is patched. Every one of those changes arrives as a transport or a technical update, and every one of them can break a process that nobody meant to touch. The diagram below shows the six layers that change underneath a live system.

Each layer changes on its own schedule. SAP Notes can arrive any week; security notes follow a monthly rhythm; support package stacks and feature package stacks follow SAP's release plan; configuration and custom code follow the business's change requests. The result is a steady stream of change that never really pauses. Every system has regression risk, but SAP concentrates it, because a change in one area often shows up somewhere else, days later, in somebody else's process. The example below is typical of a first quarter after go-live.

Five reasons SAP is especially exposed

• Integration. A sales order drives availability, delivery, goods issue, billing, revenue and margin. A change in pricing can surface as a wrong journal entry in finance.
• Shared master data. The product CMC-ALT-100 is used by sales, purchasing, production, warehouse and costing. A change to one view can affect all of them.
• Configuration-driven behavior. Much of SAP's behavior is set by customizing tables, not code. A single table entry can change determination logic for every document of a type.
• Custom code hooks. Enhancements and user exits run inside standard processes. When SAP changes the standard code around them, they can behave differently.
• Periodic processes. Month-end close, payment runs and year-end activities run rarely, so a break may not be noticed until weeks after the change that caused it.

Retesting is not regression testing. Two kinds of test follow every change, and they answer different questions. A confirmation test (often called a retest) checks that the change itself works: the defect is fixed, or the new field appears. A regression test checks that the change has not damaged anything else. Teams often do the first and call it the second. The confusion is understandable: both happen after a change, both are often run by the same key user, and both end with a pass or fail. But a retest is designed by looking at the change, while a regression test is designed by looking at everything around it. If the only person who tests a change is the person who asked for it, you almost certainly have a retest and no regression test.

The economics of run

In a project, regression is a phase near the end. In run, it is a repeating activity that happens dozens of times a year. That changes the economics. A regression approach that needs three weeks and twenty key users is tolerable once before go-live; it is impossible every month. Without a strategy, run teams drift to one of two extremes. Some test everything every time, which is slow, exhausts the key users and delays fixes, so the business starts to bypass the process. Others test only the change itself, which is fast until a quiet break reaches production and costs more to repair than all the testing that was skipped. Production defects in SAP are expensive because they are found late, after wrong documents have already been posted, shipped or paid, and each wrong document needs its own correction. The rest of this course gives you the middle path: a regression suite in tiers, ranked by risk, scheduled around SAP's delivery cadence and automated where automation actually pays.