Data provisioning services

A refreshed environment has data, but not necessarily the data a test needs. An order-to-cash test for Contoso needs a customer in sales area 1710 / 10 / 00 with a credit limit and valid pricing, unrestricted stock of CMC-ALT-100 in storage location 171A, an open posting period and a working output setup. A procure-to-pay test needs Lakeside Components with a valid purchasing info record and a purchase order above $25,000 to trigger approval. Data provisioning is the service that gets those records to the tester or the automation run, on time and unused.

Three request types

The point of the three types is to push demand down the table. Every bespoke request that recurs should become a recipe, and every recipe whose output is reused should feed the golden catalog. A data service that only takes bespoke requests is a help desk; one that turns requests into reusable assets gets cheaper every quarter.

Golden data and reservation

Golden data is a small set of master records whose settings are documented and protected: customers, materials, suppliers, pricing and credit settings that tests can rely on. In SAP the danger is consumption. A goods issue consumes stock, a billing document changes credit exposure, a payment clears open items. Two testers using the same customer on the same day can each break the other's test. Contoso solved this with reservation: each golden record carries an owner and a reservation window in the catalog, and automated runs get their own records, never shared with manual testers.

Golden data also needs replenishment. Contoso runs a nightly job in CMR and CMQ that tops up stock of CMC-ALT-100 in 171A and of CMC-RTR-200 in Detroit to fixed levels, releases expired credit blocks on golden customers, and checks that pricing conditions are valid for the next 90 days. Replenishment is cheaper than investigating a failed test every morning.

Recipes

A data recipe is a documented way to create the data one test needs, from the organizational units down to the transactional starting point. Write it first as a checklist, then automate it with whatever the TCoE uses for automation, or with SAP's own APIs and mass tools where they fit. Each recipe states its prerequisites, its outputs (the record numbers it creates, so tests can pick them up), and its cleanup. A recipe that produces "some customer" without returning the customer number is not finished.

Knowing what data a test needs

Most data requests fail because nobody wrote down what the test needs. Make data requirements part of every test case: organizational units, master data, configuration prerequisites and transactional starting points. ISO/IEC/IEEE 29119-3 has a document for this, the test data requirements, and a matching test data readiness report that records whether each requirement was met. SAP is starting to help here. In SAP Cloud ALM, the Test Data Management Agent is a Joule capability that reads the instruction text of a manual test case and returns the S/4HANA organizational units, master data, configuration and transactional fields it needs, grouped by category. It is currently part of an SAP Early Adopter Care program, and SAP's documentation states that it does not create or provision data: the example values it shows are SAP reference defaults, and the tester still sources the real records. Treat it as a way to draft data requirements, not as a provisioning service.