SAP testing explained: types, phases and owners

SAP testing is the work of proving that a configured SAP system runs your business processes correctly, with your data and at your volumes, before it goes live and every time it changes afterwards. On an S/4HANA programme it covers six types of test: unit, system integration (SIT), user acceptance (UAT), regression, performance and cutover rehearsal.

Each type answers a different question, and none of them substitutes for another. In my experience testing takes about 35 percent of programme effort, which is why it deserves its own plan, budget and owners rather than a few weeks at the end of the build.

This page is the overview. Each type has its own guide, linked from the sections below.

An SAP system is configuration, master data, custom code and interfaces working together. A change in one place can break a process somewhere else, often in a module nobody touched.

That is why SAP testing is organised around business processes rather than screens. Order to cash, procure to pay and record to report cross several modules, and a test that stops at one transaction proves very little.

Testing also does not end at go-live. Support changes, SAP releases and new rollouts all change the system, so the same discipline carries on into the Run phase.

These are the six types I plan for on an S/4HANA programme. The table shows what each one proves, when it runs and who should own it.

Testing type	What it proves	Where it sits in SAP Activate	Who owns it
Unit testing	Each configuration item, program or enhancement works on its own	Realize, inside each build sprint	Functional and technical consultants
System integration testing (SIT)	Full processes run across modules and interfaces with realistic data	Realize, in rounds once the build is stable	Programme test lead, with process owners
User acceptance testing (UAT)	The business can run its real scenarios on the system	Late Realize, before Deploy	The business
Regression testing	What worked before still works after a change	Realize onwards, then every release in Run	Test lead, with automation where volume justifies it
Performance testing	The system holds up with many users and production volumes at once	Realize, finished before go-live	Programme-level performance lead with Basis
Cutover rehearsal	The go-live sequence, data loads and timings work end to end	Deploy	Cutover manager

SAP testing across SAP Activate

1. 01

   Prepare

   Set up the test tool, the team and the test landscape.

2. 02

   Explore

   Write the test strategy while fit-to-standard decisions are made, so requirements are testable.

3. 03

   Realize

   Unit tests in sprints, then SIT rounds, performance testing and UAT once the build is stable.

4. 04

   Deploy

   Cutover rehearsals against an agreed checklist, then the go-live decision.

5. 05

   Run

   Regression testing for every support change, upgrade and release.

Unit testing

Unit testing is done by the people who built the item. A functional consultant checks a pricing condition, a developer checks an enhancement or an interface mapping.

It is necessary and not sufficient. A clean unit test tells you nothing about what happens when that item meets the rest of the process.

System integration testing

SIT is where the programme finds out whether the design works. A sales order has to flow into delivery, billing, accounting and reporting, and every interface along the way has to post correctly.

I plan SIT in rounds, not as a single pass. Defects found in the first round get fixed, and the next round proves the fixes did not break anything else. How the rounds, entry criteria and exit criteria fit together is in my S/4HANA testing strategy guide.

User acceptance testing

UAT is the business confirming that the system supports the way it will work after go-live. It belongs to the business, not to the system integrator, because only the business can accept the system.

UAT needs at least 6 to 8 weeks. Squeeze it to fit a late build and you get sign-off on paper and problems in production. My guide to SAP user acceptance testing covers scripts, roles and sign-off.

Regression testing

Regression testing reruns proven tests after a change, to catch anything the change broke. On a long programme, live support fixes and project changes both move through the system at once.

My approach is to run two separate landscapes, one for the project and one for business as usual (BAU). Live support changes and project changes are then tested apart, and neither one hides a defect in the other. My guide to SAP regression testing covers the two-landscape approach, upgrades and impact analysis.

Performance testing

Performance testing has to happen before go-live. The tests that matter most are concurrency tests, with many users running transactions at the same moment.

A transaction that is correct for one user can time out for two hundred. Functional testing will never show you that. My guide for IT leaders on SAP performance testing covers load, stress and soak tests and how to write acceptance criteria.

Cutover rehearsal

Cutover rehearsal tests the go-live itself: the sequence of technical steps, data loads, reconciliations and sign-offs, with timings. On a brownfield conversion I plan three mock conversions before cutover.

The go-live criterion I insist on is an extensive cutover checklist agreed in advance. If the checklist is written during the cutover weekend, the rehearsals were not really rehearsals.

Testing takes about 35 percent of programme effort in my experience. That figure surprises sponsors who think of testing as the short gap between build and go-live.

The effort is spread across many people. Consultants run unit tests, a test team prepares and runs SIT, business users run UAT, and Basis and integration teams support performance testing and cutover rehearsals.

Data migration sits alongside it and takes 30 to 40 percent of the effort on its own. The two overlap heavily, because every test round needs migrated data that looks like production.

The most common testing failure I see is simply not enough testing in SIT and UAT. Rounds are cut when the build runs late, and the go-live date stays where it was. Across the 21 SAP programmes I have led or rescued, the biggest mistake is still not planning properly at the start, and testing is usually where that shows up first.

Tests are only as good as the data they run on. My rule is masked data, but at production level: production-scale volumes and realistic records, with personal and sensitive fields masked.

Small, clean test data hides the problems that matter. A report that runs in seconds on a few thousand records can run for hours on a full year of postings.

The environment matters as much as the data. Plan the test landscape in Prepare, decide how it is refreshed between rounds, and keep project and BAU changes apart. My guide to SAP test data management covers copies, masking and selective test data.

My rule on automation is simple. When there is a large number of test cases that need extensive, repeated testing, automate. Below that, manual testing is fine.

Regression is where automation usually pays first, because the same tests run after every change. UAT stays largely manual, because its purpose is a business user's judgement, not a script's.

There is a practical reason to decide early. Automated tests take time to build and maintain, so they pay back only when they run many times. My SAP test automation guide covers where to start and when it pays off.

The tools fall into three groups: test management, functional automation and performance testing. Teams I have led or worked with have used Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath and LoadRunner.

This is what each group does, with the products in it:

Tool group	What it does	Products teams commonly use
Test management	Test plans, test cases, execution records, defects and traceability to requirements	SAP Cloud ALM, SAP Solution Manager, Panaya
Functional test automation	Runs scripted or model-based tests across SAP and non-SAP applications	Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft, UiPath
Performance testing	Simulates many concurrent users and production volumes	OpenText LoadRunner, now sold as OpenText Professional Performance Engineering

A few product facts are worth knowing before you choose.

1. SAP Cloud ALM is included for customers with SAP Enterprise Support or a cloud subscription that contains Enterprise Support, cloud editions (SAP Support). Its test management covers test preparation, test plans and execution, including manual test cases for UAT (SAP Learning).
2. SAP Solution Manager 7.2 mainstream maintenance ends at the end of 2027, with optional extended maintenance to the end of 2030 for a subset of functions, including the test suite (SAP Support).
3. SAP Test Automation by Tricentis is SAP's resold automation product, integrated with SAP Cloud ALM and built for SAP and third-party systems (SAP).
4. LoadRunner is an OpenText product. LoadRunner Professional is now called OpenText Professional Performance Engineering, and it supports SAP GUI and SAP Web protocols (OpenText).

If you are starting a new programme, plan test management in Cloud ALM rather than Solution Manager. For a deeper comparison, read my guide to SAP testing tools.

On SAP Cloud ERP public edition (S/4HANA Cloud Public Edition), SAP upgrades every customer on its own schedule. SAP Learning describes upgrades every six months, currently in February and August, with new features delivered monthly in between (SAP Learning).

You do not choose the upgrade date, so regression testing becomes a fixed calendar item rather than a project. This is the strongest case for automating regression early on a public cloud system.

On private cloud and on-premise you control the timing of upgrades. Each one still needs a regression cycle sized to the processes the change touches.

Before anything else, put testing into the plan as a workstream with its own owner and budget, sized at about a third of the effort. Then name the business owner for UAT and block 6 to 8 weeks for it in the calendar now, before the build squeezes it.

Tie test results to your go/no-go decisions with measurable exit criteria. My guide to SAP quality gates shows how. If your programme is already in trouble, my notes on SAP programme recovery cover what to fix first.

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

What is SAP testing?

SAP testing proves that a configured SAP system runs your business processes correctly, with your data and at your volumes. On an S/4HANA programme it includes unit testing, system integration testing, user acceptance testing, regression testing, performance testing and cutover rehearsal. It carries on after go-live for every support change and release.

What are the types of SAP testing?

The six main types are unit testing, system integration testing (SIT), user acceptance testing (UAT), regression testing, performance testing and cutover rehearsal. Unit tests check single items, SIT checks full processes across modules and interfaces, and UAT is the business accepting the system. Regression, performance and cutover rehearsal protect against changes, load and the go-live itself.

How long does SAP user acceptance testing take?

Plan at least 6 to 8 weeks for UAT. The business should own it, run its real scenarios and sign it off. Not enough testing in UAT and SIT is the most common testing failure I see.

How much of an SAP project is testing?

In my experience testing takes about 35 percent of programme effort. That covers preparing and running unit tests, SIT rounds, UAT, regression, performance testing and cutover rehearsals. Data migration runs alongside it and needs production-like data for every test round.

Should SAP testing be automated?

Automate when you have a large number of test cases that need extensive, repeated testing, which usually means regression. Below that, manual testing is fine. UAT stays largely manual, because its purpose is the business's judgement.

Which tool is used for SAP testing?

Most programmes combine a test management tool with an automation tool and a performance testing tool. Common choices are SAP Cloud ALM or Solution Manager for test management, Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft or UiPath for automation, and OpenText LoadRunner for performance. New programmes should plan on Cloud ALM, since Solution Manager mainstream maintenance ends in 2027.