SAP test automation: where to start and when it pays

SAP test automation means turning the SAP tests you run again and again, mostly regression, into tests a tool executes instead of people. It pays off when a large number of test cases need extensive, repeated testing; below that, manual testing is fine.

That is the rule I use on S/4HANA programmes. In my experience testing takes about 35 percent of programme effort, so the question is never whether to test. It is which part of that effort a tool should carry.

For how automation fits alongside unit, integration, acceptance and performance testing, start with my overview of SAP testing explained. This article covers where to start, when automation pays, the frameworks, and what SAP Cloud ALM, Solution Manager and Tricentis give you.

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

The reason is the cost shape. An automated test costs more to build than to run once by hand, and it needs maintenance every time the process, screen or data changes. You earn that back only through repetition.

On an SAP programme, repetition comes from predictable places:

1. Transports. Every change moved into the quality system can break something that worked yesterday.
2. SAP releases and support packages. Upgrades on-premise and in private cloud, and the scheduled upgrades on SAP S/4HANA Cloud Public Edition.
3. Repeated test rounds. System integration testing (SIT) runs the same end-to-end flows in more than one round.
4. Rollout waves. A global template gets tested again for each country or company code.
5. Data-heavy checks. Many combinations of pricing, tax or account determination, where only the data changes.

If none of these apply, a tool will cost you more than it saves.

The table shows how I would split the work by test type.

Test type	Automate?	Why
Regression of core processes such as order to cash, procure to pay and record to report	Yes, first	Runs after every transport and every release
SIT rounds	Partly	Automate stable flows; keep new and changing scenarios manual
User acceptance testing (UAT)	Rarely	Business users judge whether the process works for them, which a script cannot
Exploratory and negative tests	No	The value comes from a person looking for what nobody scripted
Performance and load	Yes, with a load tool	Many concurrent users cannot be produced by hand
One-off data migration checks	Usually not	Reconciliation reports do this better, unless the same load repeats across mock runs

Decide

Should you automate this SAP test?

Many test cases, repeated after every change or release

→Automate it

Few test cases, or run once or twice

→Test it manually

Process design still changing

→Wait until it is stable, then decide

Automation that disappoints usually started too wide: everything, during design, with nobody owning the result. This is the order I would follow:

1. Pick the processes the business cannot afford to break. Month-end close, billing, payments and anything rolled out across many sites come before nice-to-have reports.
2. Run the tests manually first. A tool automates a test that already works by hand. It does not design one for you.
3. Wait for a stable design. Automating during Explore or early Realize means rebuilding the tests every time a design decision changes.
4. Build a small regression pack. Cover the critical processes end to end, then run the pack on every transport into the quality system.
5. Name an owner for maintenance. Somebody has to fix tests when screens, roles or data change, or the pack decays within a few releases.
6. Grow coverage only where repetition justifies it. Add a test when it will run often, not because a coverage target says so.

Separate the project from business as usual

During a programme, I 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.

That matters for automation. When a regression test fails, you want one source of change to investigate, not two mixed together. My guide to SAP regression testing covers the two-landscape approach and impact analysis in more depth.

Across my programmes I have used, or had my teams use, Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath and LoadRunner. This article does not rank them. The right choice depends on your landscape, your support contract and who will maintain the tests.

Start with what SAP already provides, because part of it may already be paid for.

SAP Cloud ALM

SAP Cloud ALM is the test management layer. It plans, runs and traces manual and automated tests against your processes and requirements. Customers with SAP Enterprise Support, Product Support for Large Enterprises or an eligible cloud subscription can provision one tenant (SAP usage rights).

It does not execute automated tests itself. SAP states that Cloud ALM has no home-grown automation engine and that its ALM platforms stay open to third-party test automation (SAP Support, test automation).

SAP's setup guide describes built-in integrations plus a public Test Automation API for other providers (SAP Help Portal). Panaya and UiPath document Cloud ALM integrations for automated test cases. Worksoft lists Cloud ALM and Solution Manager among its integrations, and OpenText offers a Cloud ALM integration for its cloud performance testing product.

Tricentis Test Automation for SAP and SAP Test Automation by Tricentis

Check your entitlement before you buy anything. SAP grants a term licence for Tricentis Test Automation for SAP, integrated with Cloud ALM, with SAP Enterprise Support, Enterprise Support cloud editions and Product Support for Large Enterprises. It currently runs to 31 December 2028 (SAP usage rights).

The limits are tight: 5 named users, 500 test runs a calendar month, 5 customer-managed execution agents and 12 months of result retention. It may not be used to automate productive business processes. Treat it as a way to start, not as a programme-scale tool.

SAP Test Automation by Tricentis is the paid step up. It is a software-as-a-service product that SAP sells and supports as a solution extension, covering SAP and third-party applications. It extends the Tricentis capability included with Cloud ALM when the entitlement runs out of room.

SAP Solution Manager

Solution Manager 7.2 mainstream maintenance runs until the end of 2027. Customers who opt into extended maintenance for SAP Business Suite 7 get Solution Manager extended maintenance to the end of 2030. It covers a limited set of areas, including the test suite (SAP Support).

Its own automation, Component-Based Test Automation (CBTA), will not be extended to SAP cloud products. The Tricentis licence for the Solution Manager integration currently runs to 31 December 2027. If you already run Solution Manager, keep it until your landscape moves, but do not build new automation around it.

SAP S/4HANA Cloud Public Edition

Public Edition comes with its own Test Automation Tool. SAP's guidance is that partners create or update test automates as they configure each process, so they can run in the test system during upgrades (SAP Learning).

With your consent, SAP runs post-upgrade tests on standard, unmodified processes. After go-live you own regression testing for anything you have customised, using your own automates.

The table summarises the tools named above by job, not by preference.

Tool	Main job	Where it fits
SAP Cloud ALM	Test management and orchestration	New programmes; connects manual and automated tests to processes
SAP Solution Manager	Test management, on-premise	Landscapes already running it; mainstream maintenance ends 2027
Tricentis Tosca and SAP Test Automation by Tricentis	Model-based automation	SAP and non-SAP applications; resold and supported by SAP
Worksoft	Codeless process automation	Integrates with Cloud ALM and Solution Manager
Panaya	Test management and codeless automation	Cloud ALM integration for automated tests
UiPath	Automation platform with Test Manager	Cloud ALM integration for automated test cases
OpenText LoadRunner	Performance and load testing	Concurrency and volume tests before go-live

For a deeper comparison, including Xray for Jira, read my guide to SAP testing tools. For load testing, read SAP performance testing for IT leaders.

The tool matters less than how the tests are built and who maintains them. Most SAP automation falls into one of these approaches:

1. Model-based. Screens and APIs are scanned into reusable modules, then assembled into test cases. Functional consultants can build and read them without code.
2. Codeless process capture. Business process steps are recorded and turned into reusable tests. This suits teams where key users help build the regression pack.
3. Code-based. Test engineers write tests in a programming framework. It fits Fiori apps and APIs owned by a development team, and needs developers to maintain.
4. Robotic process automation platforms with testing modules. One platform for business automation and test automation, useful if you already run it.
5. SAP-delivered automates. On Public Edition, test automates delivered with the Test Automation Tool, adapted to your data and changes.

Whichever approach you pick, three design choices decide whether the tests survive:

1. Test at the API level where you can. API tests break less often than tests that click through screens.
2. Keep test data resettable. A test that depends on data used up by the last run fails for the wrong reason.
3. Build from shared modules. When a screen changes, you fix one module, not every test that touches it.

An automated regression pack is a product, not a project deliverable. It needs an owner, a budget line and a place in the change process.

Tie it to change control. No transport moves to production until the regression pack has run and its results are recorded in the test management tool. My article on SAP quality gates shows how to make test results part of a go or no-go decision.

Plan for SAP's release rhythm too. Public Edition upgrades arrive on SAP's schedule, not yours, and private cloud and on-premise systems still need support packages and upgrades. Each one is a regression run, which is exactly where automation earns back its cost.

Fix flaky tests, retire tests nobody runs, and keep the pack small enough that people trust its results.

Automation also has to sit inside a test plan. Cycles, entry and exit criteria and roles come first; my S/4HANA testing strategy sets them out.

List the business processes you would retest after every transport and every SAP release. Count the test cases behind them and how often each would run in a year.

If the count is large and the runs repeat, you have a case for automation. Then check what your SAP support contract already includes before anyone shows you a demo.

If you want an independent view on a test automation plan or a vendor proposal, I help organisations with this. You can contact me here.

What is SAP test automation?

It is the use of a tool to execute SAP tests that would otherwise be run by hand, mostly regression tests after changes and upgrades. A test management tool such as SAP Cloud ALM plans and records the tests, and an automation tool runs them.

When should you automate SAP testing?

When a large number of test cases need extensive, repeated testing, such as regression after every transport, release or rollout wave. Below that, manual testing is fine. Wait until the process design is stable, or you will rebuild the tests every time the design changes.

Does SAP Cloud ALM do test automation?

It manages and triggers automated tests but has no automation engine of its own. It integrates with Tricentis Test Automation for SAP, with the Test Automation Tool in S/4HANA Cloud Public Edition, and with other providers through a public Test Automation API.

What is SAP Test Automation by Tricentis?

It is a software-as-a-service test automation product that SAP sells and supports as a solution extension, covering SAP and third-party applications. It extends the entry-level Tricentis Test Automation for SAP licence included with SAP Enterprise Support. That licence is capped at 5 named users and 500 test runs a month.

Can you automate SAP user acceptance testing?

Rarely, and it should not be the goal. UAT exists so business users can judge whether the system works for them, which a script cannot do. Automate the repeated regression around it and keep the acceptance decision with people.

Should I still use SAP Solution Manager for test automation?

Only if it already runs your landscape. Mainstream maintenance for Solution Manager 7.2 ends in 2027, and its CBTA automation will not be extended to SAP cloud products. Plan new automation around Cloud ALM.