S/4HANA testing strategy: cycles, criteria and roles

An S/4HANA testing strategy decides which test cycles you run, in what order, who owns each one and what evidence lets you move from one to the next. On my programmes it covers system integration testing (SIT) in rounds, user acceptance testing (UAT) in rounds and regression testing, each with written entry and exit criteria and a named sign-off.

Testing takes about 35 percent of programme effort on the S/4HANA programmes I plan, so the strategy deserves as much care as the build plan.

The testing types themselves are covered in my SAP testing explained guide. This article is the strategy layer: cycles, criteria, roles and the document outline.

SAP Activate puts most of the testing in Realize. SAP's own test strategy material for S/4HANA Cloud Private Edition treats unit and string tests as informal. Full business process, integration, data migration and user acceptance tests are formal and must be documented.

This is the sequence I plan on an S/4HANA programme:

S/4HANA test cycles

1. 01

   Unit and string

   Consultants test each configured function and short chains as they build.

2. 02

   SIT rounds

   Full process chains across modules, interfaces and migrated data.

3. 03

   UAT rounds

   Business users prove the system runs their processes, round by round.

4. 04

   Regression

   Retest what already passed after fixes, transports and releases.

5. 05

   Mock conversions and rehearsal

   Run the cutover as it will run on the night, against the checklist.

6. 06

   Go-live

   Go only when the agreed cutover checklist is complete.

Unit and string testing

Consultants and developers test each configuration item and each development as they build it. String tests chain a few steps together, such as a sales order through to delivery.

Informal in SAP's terms, but not optional.

System integration testing in rounds

SIT tests complete business processes across modules, interfaces and converted or loaded data. I plan it in rounds rather than as one event, so defects fixed after one round are retested in the next.

I do not have a fixed number of SIT rounds. The count depends on the number of processes, interfaces and entities in scope, and the strategy should say how many rounds and why.

User acceptance testing in rounds

UAT is where the business confirms the system runs its processes, with its own people and realistic data. Like SIT, I plan it in rounds, so fixes from one round are retested in the next.

UAT needs at least 6 to 8 weeks. Business testers do this alongside their normal jobs, and they need time for more than one round. My guide to SAP user acceptance testing covers scripts, rounds and sign-off in detail.

Regression testing

Every fix, transport and release can break something that already passed. Regression testing reruns the processes that matter after each change, during the programme and after go-live.

SAP's material places regression mainly in Run, after release upgrades, but a programme needs it earlier too. The approach, impact analysis and environment setup are in my SAP regression testing guide.

Mock conversions and cutover rehearsal

On a brownfield conversion I plan three mock conversions before cutover. Each one tests the conversion itself, the timings and the reconciliation, not only the processes.

The last rehearsal should run like the real night: same sequence, same people, same checklist. My S/4HANA migration timeline and project plan shows where these runs sit in the plan.

The single most important ownership decision: the business owns user acceptance testing. Not the system integrator and not IT.

An integrator can prepare scripts and fix defects. Only the people who run your finance close, order-to-cash or plant can confirm those processes work.

SAP's own guidance points the same way. Partner configuration experts create the test cases, and customer line-of-business experts execute UAT and record the results.

This is how I would split ownership across the cycles:

Cycle	Owner	Executes	Signs off
Unit and string	Build team lead	Consultants and developers	Functional and technical leads
SIT rounds	Test manager	Consultants, with key users joining later rounds	Test manager and process owners
UAT rounds	The business, through named process owners	Key users and business testers	Process owners, then the sponsor
Regression	Test manager	Test team, automated where volume justifies it	Test manager and change board
Mock conversions and rehearsal	Cutover lead	Technical, data and functional teams	Cutover lead, data lead and sponsor

Write the names into the strategy, not the roles. "Finance process owner" is a role; a named person who has agreed to sign is an owner.

Entry criteria stop a cycle starting before it can succeed. Exit criteria stop it ending because the calendar says so.

Write both before Realize starts, while nobody is under deadline pressure. My guide to SAP quality gates explains how these criteria become formal gates with an owner who can say "not ready".

The table below is guidance to adapt, not a standard to copy. Set the percentages and defect limits with your sponsor and record them in the strategy:

Cycle	Entry criteria	Exit criteria
Unit and string	Design signed off; configuration and development complete for the items under test	All items tested and documented; defects fixed or logged against SIT
SIT round	Unit testing complete for the processes in scope; test environment built and interfaces connected; test data loaded; scripts reviewed	Agreed share of scripts executed and passed; no open critical defects; open lower defects each have an owner and a fix date
UAT round	SIT exit criteria met; business testers named and released from day jobs; scripts reviewed by process owners; training on the test system done	Every in-scope process executed by business users; no open critical defects; process owners have signed their processes
Regression	A change, fix batch or release ready to move; regression pack agreed for the affected processes	Regression pack passed; any failure fixed and retested before the change moves on
Mock conversion or rehearsal	Production copy available; cutover checklist and run book drafted; reconciliation rules agreed	Conversion or load completed inside the planned window; reconciliation signed by the data lead; checklist updated with lessons
Go-live	All prior exit criteria met; cutover checklist agreed in advance	Every checklist item complete and signed; go or no-go recorded by the sponsor

Two rules make the table work. Every criterion gives a yes-or-no answer, and every exit has a named signatory.

If a cycle misses its exit criteria and the business still wants to move on, make it a written decision. Name the person who accepted the risk and the defects carried forward.

The test manager writes it in Prepare or early Explore, and the sponsor approves it. Keep it short enough that process owners read it.

These are the sections I expect to see:

1. Scope and objectives. Which processes, entities, interfaces and reports are tested, and which are explicitly out.
2. Test types and cycles. Unit, string, SIT rounds, UAT rounds, regression, performance, data migration testing and mock conversions, with the number of rounds and the reasoning.
3. Schedule and effort. Dates for each cycle inside the SAP Activate plan, with UAT given at least 6 to 8 weeks, and the effort budgeted against the roughly 35 percent testing share.
4. Roles and ownership. The ownership table above, with names.
5. Entry and exit criteria. One set per cycle, with the signatory for each.
6. Environments. Which systems are used for which cycle, how they are refreshed and how project changes are kept apart from live support changes.
7. Test data. Where the data comes from, how it is masked and how it is refreshed between rounds. My guide to SAP test data management covers this in depth.
8. Defect management. Severity definitions, triage cadence, who decides priority and the target fix time per severity.
9. Tools. Where test cases, results, defects and sign-offs live, with one system of record.
10. Automation approach. Which tests are automated, which stay manual and why.
11. Reporting. What the weekly test report shows and who receives it.
12. Cutover and go-live criteria. The cutover checklist, the rehearsals that prove it and who makes the go or no-go call.
13. Risks and assumptions. Tester availability, environment dates, data readiness and dependencies on third parties.

On tools, SAP Cloud ALM is the default for new programmes. SAP states there is no separate licence for SAP Cloud ALM: it is included with Enterprise Support, and its test management apps hold the formal test cases, runs and results.

SAP Solution Manager 7.2 is still in use on many programmes, but its mainstream maintenance ends at the end of 2027. For automation, SAP sells SAP Test Automation by Tricentis, which works with Cloud ALM; my SAP testing tools comparison covers the wider choice.

The most common testing failure I see is not enough testing in UAT and SIT.

A common mechanism: build runs late, the go-live date stays fixed, and the weeks come out of the test cycles because they sit at the end of the plan.

These are the patterns that cause it, and what to do about each:

1. SIT starts before unit testing is finished. The first SIT round becomes a unit test round. Hold the entry criteria.
2. UAT is planned for two or three weeks. Business users cannot test properly alongside their day jobs in that time. Plan at least 6 to 8 weeks and release the testers.
3. The integrator runs UAT for the business. The scripts pass, and the business finds the gaps after go-live. Keep UAT ownership with the process owners.
4. Testing is budgeted as a small line item. At about 35 percent of effort, testing that is budgeted at a fraction of that gets cut first.
5. Exit criteria are written during the cycle. They end up matching whatever the team has achieved. Write them before Realize.
6. Go-live is decided on confidence, not a checklist. Nobody can show what was agreed, so nobody can say what is missing.

That last point is the one I insist on. My go-live criterion is an extensive cutover checklist, agreed in advance with the business, IT and the integrator.

It covers technical steps, data loads, reconciliations, business validations, interface switches, user access and go or no-go points. If an item is not complete and signed, the programme is not ready, whatever the date says.

Before Realize starts, ask your test manager for the test strategy document and check it against the outline above. If it has no named UAT owner, gives UAT less than 6 to 8 weeks or has no entry and exit criteria per cycle, fix that first.

If you want an independent review of a testing strategy or a go-live checklist, I help organisations with this. You can contact me here.

What is an S/4HANA testing strategy?

It is the plan that decides which test cycles run, in what order, who owns and signs off each one and what evidence lets the programme move from one cycle to the next. On an S/4HANA programme it usually covers unit and string testing, SIT rounds, UAT rounds, regression, data migration testing and cutover rehearsals.

How much of an S/4HANA programme is testing?

On the programmes I plan, testing takes about 35 percent of programme effort. Budget it at that level from the start, because testing that is underfunded is the first thing cut when build runs late.

How long should UAT take on an S/4HANA project?

At least 6 to 8 weeks. Business testers run UAT alongside their normal jobs, and they need time for more than one round so fixes from the first round are retested.

Who should own user acceptance testing in SAP?

The business, through named process owners. The system integrator can prepare scripts, manage the environment and fix defects, but only the people who run the processes can confirm the system works for them.

What are entry and exit criteria in SAP testing?

Entry criteria are the conditions a cycle needs before it starts, such as finished unit testing, a built environment and loaded test data. Exit criteria are the conditions it must meet before it ends, such as scripts executed, no open critical defects and process owner sign-off. Each should give a yes-or-no answer and have a named signatory.

What should an S/4HANA go-live checklist include?

Technical cutover steps, data loads and reconciliations, business validations, interface switches, user access and the go or no-go decision points. Agree it in advance, rehearse it in the mock conversions or dress rehearsal and go live only when every item is complete and signed.