Moving from SAP ECC to S/4HANA generates more manual test execution than almost any other program a business will run. Four named test levels, several cycles each, repeated at every wave and every transport — and most of it executed by hand, often by a systems integrator whose people eventually leave.
These templates are for that program: the strategy and the three plans, written for how the work is really organized, with the automation-candidate question asked at each level rather than bolted on at the end.
IMG_01
The four levels
|
TUT Technical Unit Test |
Custom objects in isolation — the WRICEF items. Developer-executed, evidence attached to the object. Interfaces and conversions are where this level earns its keep. |
|
FUT Functional Unit Test |
One configured process step at a time. These scripts are the raw material for SIT and, later, for your regression suite — which is why it pays to write them as though somebody else will execute them. |
|
SIT System Integration Test |
End-to-end business processes across modules, interfaces and surrounding systems. Where most defects are found and most effort is spent, usually over two to four cycles. |
|
UAT User Acceptance Test |
The business decides whether it can do its job. In an S/4HANA program this is also most users’ first extended contact with Fiori, which shapes the verdict as much as the configuration does. |
Be precise about what can be automated
This is the single most useful thing to settle early, and it is a question of access route rather than of process.
Studio drives a real browser. That covers SAP Fiori and SAP GUI for HTML (Web GUI), along with the surrounding web applications in scope — Ariba, SuccessFactors, Concur, supplier and customer portals, and your own custom front ends. It does not drive SAP GUI for Windows, which is a desktop client.
So classify every in-scope transaction by its access route during the Explore phase. That one column tells you honestly how much of your regression burden is addressable, and it prevents the expensive discovery in cycle two of SIT that half the scope is desktop-only. The strategy template has the table for it.
Where the automation case actually is
Not in the first pass of any level. It is in the repetition: the same end-to-end scenarios executed by hand in SIT cycle 1, again in cycle 2, again in UAT, again at the next wave, and again at every support pack for years afterward.
A scenario that has been walked by hand three times is already fully specified — the steps exist, and so do the expected values. Describing it once in plain language turns it into a test that runs on every transport from then on. That is where a phased program gets its capacity back, and it is why the candidate question belongs in the SIT plan rather than in a separate automation workstream.
Two things to agree with your systems integrator
- Who owns the regression suite after go-live. A suite built by the SI that nobody on your side can read becomes unmaintainable the day they leave. Plain-language tests are materially easier to hand over than scripted ones, but make handover a contractual deliverable either way.
- Who provisions and refreshes test data. In an S/4HANA program this causes more failed cycles than defects in the software do.
The documents
Four documents covering the test levels an S/4HANA program actually runs:
- SAP S/4HANA Test Strategy — the program-level document
- SAP TUT and FUT Test Plan — technical and functional unit testing
- SAP System Integration Test Plan — end-to-end across modules and interfaces
- SAP User Acceptance Test Plan — business sign-off
Each one includes an automation-candidate table and the access-route classification, so the question gets asked at every level rather than once at the end.
Not running an SAP program?
The general-purpose set covers the same ground without the SAP phasing — see Test Strategy Templates You Can Use Today.