Writing for handover and automation

At go-live the test pack changes owners. At Contoso, the system integrator's testers leave after hypercare and Contoso's internal team takes over regression testing for quarterly updates and support packs. Some of the pack will be automated later. Both groups inherit what you wrote, without you there to explain it. This lesson collects the habits that make a test case transferable. None of them is expensive at the time of writing. All of them are expensive to retrofit, because by the time a pack is handed over the people who knew the missing details are busy elsewhere or gone. A handover-ready test case has six properties:

• Self-contained: everything needed to run it is in the case or in a referenced data set; nothing lives only in the author's head or in a chat thread.
• Deterministic: the same data and the same system state give the same result. Waits for background jobs, output processing or workflow are stated explicitly.
• One verdict per check: each expected result can be marked pass or fail on its own, so a partial failure is visible.
• Parameterized: data comes from the data set and runtime values, never from literal numbers in the steps.
• Restartable: postconditions and cleanup are stated, so the case can run again in the next cycle.
• Owned and versioned: an owner, a version, a change note and a review status, so the next person knows whether it is current.

Two of these properties trip up SAP packs more than the others. Determinism suffers from background processing: output, workflow, batch jobs such as billing due list runs and interfaces may not complete the instant the user saves. A step that says "check the invoice output" without saying how long to wait, or which job must run first, gives different results for different testers. Restartability suffers from consumed data, covered in lesson 2. Both are fixed by writing down what the author knows implicitly: which job, how long, and what to reset.

Next, build from reusable blocks. Large SAP scenarios are long chains, and long chains are where handover breaks first. Rather than writing one 60-step monolith for "order to cash with credit check, partial delivery and payment", write reusable building blocks and chain them. Each block is a small test case with its own inputs, outputs and checks. The same blocks then serve other scripts: "create billing document" is reused in the partial-delivery and the returns scenarios, and "post incoming payment" is reused by the finance team's cash application tests. In SAP Cloud ALM, test cases are built from solution process activities and can be reused across several test plans and cycles, which rewards this design. When a block changes, for example because a new mandatory field appears on the sales order, you change it once and every script that uses it is current again. Keep each block's inputs and outputs listed at the top, so whoever chains it can see what it needs and what it hands on.

Ready for automation

Automation does not fix a vague test case; it runs the vagueness faster. An automation engineer converting your script needs every step to be unambiguous and every check to be something a tool can compare. The table shows typical conversions.

Which SAP tool does the conversion depends on your landscape. For SAP S/4HANA Cloud Public Edition, SAP provides the Test Automation Tool, which works with SAP Cloud ALM. On-premise and Private Edition landscapes have historically used eCATT and, with SAP Solution Manager, component-based test automation (CBTA); check the current SAP guidance for your release before committing, because tool support changes over time. The writing discipline is the same whichever tool your project picks, and it pays off even if nothing is ever automated: a script an automation engineer could convert is also a script a new tester can run without asking questions. One more habit helps both audiences. Use the same business terms throughout the pack, matching the terms in the process design, and keep a short glossary with the data sheets. If one script says "customer", another "sold-to party" and a third "account" for the same thing, the next owner will wonder whether they are different.