What should you automate first in SAP?

The question

Most SAP automation programmes begin with the same instinct: find the tests that take the longest to run manually, and automate those first. It feels obviously correct. It is usually wrong.

The duration of a manual test is a fact about one execution. The value of automating it is a fact about all future executions. Those two numbers can point in completely opposite directions, and the second one is the one that pays.

What we see in programmes

The pattern that causes most disappointment looks like this. A programme automates aggressively during implementation, reaches a large number of automated scenarios, and reports it as a milestone. Twelve to eighteen months later the suite is largely unused. Scripts fail for reasons that turn out to be environmental. Nobody has clear ownership of fixing them. Running the suite produces a list of failures that takes longer to triage than testing manually would have taken, so people stop running it.

Nothing went wrong technically. What went wrong is that a large number of scenarios were built against processes that were still moving, with no maintenance model behind them, and the volume itself became the problem. Every automated scenario is a small ongoing commitment. Build more of them than you can service and the suite decays — not evenly, but unpredictably, which is worse, because you no longer know which parts to trust.

The second pattern is subtler: automation built for the demo rather than for the release. A scenario that runs beautifully in a controlled environment with prepared data, and cannot run in the environment and data conditions that exist during an actual regression cycle.

A better way to think about it

Four questions, asked before anything is built. A candidate needs a reasonable answer to all four, not to one of them.

Is it repeatable? Will this genuinely be executed again, as part of a regression cycle, on a schedule somebody has committed to? If the honest answer is that it runs once at the end of the implementation, automation is the wrong tool.

Is it business-critical? If it failed in production and nobody noticed for a week, it is probably not where the first automation effort belongs. Criticality is what justifies the maintenance commitment.

Is it stable? Is the underlying process settled enough that the script will not need rewriting every sprint? This is the criterion most often skipped, and the one that most often kills a suite. An important process that is still being designed is a poor candidate today and an excellent candidate in three months.

Is it reusable? Will automating this create value across future regression cycles, releases and upgrades — or is it a one-off shape that will never be needed again in this form?

Not every test should be automated. The objective is sustainable regression coverage, not automation volume.

What good looks like

A candidate list before a build plan. The output of the selection exercise should be a written list of what will be automated, what will stay manual, and why — reviewed with the people who own the processes. This document is more valuable than it looks, because it is what stops scope creeping into the suite six months later.

Deliberate manual scope. Some things should stay manual permanently and it is a sign of maturity to say so. Exploratory testing of a new process. Anything requiring human judgement about whether an output looks right. One-off validations. Highly volatile areas.

A named maintenance owner from day one. Not a plan to appoint one later. The question “who fixes this when the UI moves?” should have a name attached before the first scenario is built.

Failures triaged, not just counted. A regression run that produces forty failures is useless until somebody has separated the genuine defects from the environment noise. This work is real, it recurs every cycle, and it should be planned for rather than discovered.

SAP’s own positioning around continuous testing points the same way: the value is in protecting critical business processes through ongoing change, which is a statement about repetition rather than about volume. SAP Cloud ALM holding both manual and automated test cases centrally reflects the same idea — the two are complementary parts of one coverage picture, not competing scoreboards.

Questions leadership should ask

How many of our automated scenarios ran in the last regression cycle, and how many passed first time? The gap between “scenarios built” and “scenarios that ran” is the health of the suite.

Who owns maintenance, and is it in their objectives?

What did we deliberately decide to keep manual? If the answer is nothing, the selection exercise did not happen.

How long does it take to triage a failed run? If it is longer than running the tests manually, the suite is not yet an asset.