Preconditions and data references

The most common reason an SAP test case fails on its second outing has nothing to do with the system under test. The case pointed at data that no longer exists, or assumed a setup that nobody wrote down. This lesson covers the two parts of a test case that carry it from one cycle to the next: preconditions and test data. A precondition is anything that must already be true before step 1. Write each one as a statement the tester can confirm in a minute, and agree with the test lead that a missing precondition produces a blocked result instead of a misleading fail. That distinction matters at sign-off: a fail says the system is wrong, a block says the test could not be run fairly. For SAP, preconditions usually fall into a handful of groups.

Why hard-coded data breaks

A script that says "display sales order 1000457" or "use customer 17100001" works exactly once in exactly one system. SAP test data is fragile in predictable ways:

• Refreshes and copies: when QAS is refreshed from production or rebuilt for a new cycle, documents created during testing are gone and number ranges restart from wherever the source left them.
• Consumption: a sales order that has been fully delivered and billed cannot be delivered again; stock that was issued is no longer there; an invoice that was paid cannot be paid twice.
• Collisions: two testers using the same order or the same stock in parallel change each other's results.
• Landscape differences: the same customer may carry a different number in the training client, the sandbox and QAS.
• Time: price records and contracts have validity dates, posting periods close, and a delivery date that was in the future during cycle 1 is in the past by cycle 3.

The fix is to separate what the test does from which data it does it with. Steps refer to roles in the data ("the customer in the data set", "the product in the data set"), and a separate data sheet holds the actual values for this cycle and this system. When the system is refreshed, you update one data sheet instead of 200 scripts. The data sheet also becomes a planning tool: before each cycle, the data owner checks every row against the refreshed system, creates what is missing, and marks the sheet ready. Testers who find a sheet not marked ready know to stop before they waste a morning on false failures.

A variant is one row of data for the same steps. Contoso's order-to-cash case runs with variant A (Great Lakes Fleet Services buying 50 alternators CMC-ALT-100 from plant 1710), variant B (a tax-exempt customer) and variant C (a partial delivery of 30 then 20). One set of steps, three outcomes, and three expected-result rows in the data sheet. Give every data set an owner, usually the key user for the process, and a "valid for" line naming the system, client and cycle, so a tester can tell at a glance whether the sheet is current. Documents created during the run are runtime values. Write them as placeholders and tell the tester to record them: "Create the delivery for the order created in step 2 (record as ORDER_NO)". Later steps then say "for ORDER_NO". The execution record holds the real numbers, which also gives a reviewer the evidence trail.

SAP's own test automation follows the same principle. In eCATT, a test configuration combines a script with variants of data, and SAP's documentation describes referencing a test data container as the preferred method over typing values into the configuration, so values can be changed in one place for every test that uses them. A manual script that already keeps its data in a referenced sheet is far easier to convert later, because the separation of steps and data has been done. If your project uses SAP Cloud ALM, keep the data sheet next to the test case (as an attachment or a linked document, depending on what your tenant supports) so the two travel together.