S/4HANA regression automation: what to automate first

Every SAP automation initiative starts with enthusiasm and a long list. Most stall within a year with a few hundred scripts that nobody trusts. The difference between the ones that stall and the ones that last is rarely the tool. It is what they chose to automate first and how they built it.

Choose by risk and change, not by ease

The tempting first targets are the easy ones: a master data display, a simple report. They demo well and protect almost nothing. Rank candidates on two questions instead: how much damage does a failure here do to the business, and how often does something change that could break it?

For most S/4HANA landscapes the top-left quadrant is remarkably consistent: order-to-cash (order, delivery, goods issue, billing, payment), pricing and credit checks, procure-to-pay through invoice verification and the payment run, and the interfaces that feed or drain them.

Automate processes, not transactions

A script that creates a sales order in VA01 and checks for a document number tells you very little. A test that creates the order, delivers it, posts goods issue, bills it and checks the accounting document and the customer balance tells you whether you can still make money. Build the second kind.

• Chain the documents. Pass the order number to the delivery, the delivery to billing, the billing document to the FI check.
• Assert on outcomes, not screens. The posted amounts, the stock quantity, the open item. A green screen message is not proof.
• Build reusable components.“Create sales order” should exist once, with parameters, and be used by every test that needs an order.

Plan for both SAP GUI and Fiori

S/4HANA users rarely live entirely in one interface. Finance may keep SAP GUI transactions while sales moves to Fiori apps, and many processes cross both. Your automation approach has to handle SAP GUI (or SAP GUI for HTML), Fiori and the APIs underneath, ideally within the same test. Check that before you commit to a tool, using your own processes, not a vendor’s prepared demo.

Keep it alive

The second year is what kills automation suites. Plan for it from the first test:

• Data independence.Each test creates or reserves its own data, or reads it from a managed pool. Tests that depend on yesterday’s purchase order fail after every client refresh.
• Ownership. Every test has an owner in a process team who agrees what it should check.
• Run it on a schedule. A suite that only runs before releases is always broken before releases. Run critical paths nightly or on every transport into quality.
• Self-healing and AI. Modern tools can repair tests when a Fiori layout changes, suggest tests from process documentation and triage failures. Use them, but keep a human reviewing what the suite checks.

Measure what matters

Report on three numbers and ignore vanity counts:

1. Critical process coverage: of your top processes, how many have an automated end-to-end test?
2. Regression cycle time: how long from “release ready to test” to “results in hand”?
3. Escaped defects: how many production incidents came from changes the suite should have caught?

Next: test data for S/4HANA, the part that breaks most SAP tests.