ERP regression suites die of incompleteness: everyone tests the standard order, nobody tests the partial delivery with a credit block in a foreign currency. This playbook generates the scenario matrix from your functional specs — then generates synthetic master data that honors your actual configuration, so every scenario is runnable.
Tier: Core · Workflow area: ERP Development & Testing · ~35 minutes
Test design is combinatorial and human testers are not: the order-to-cash flow alone multiplies order types × payment terms × delivery scenarios × credit statuses × currencies into hundreds of paths, of which a typical manual suite covers a few dozen — the familiar ones. LLMs are relentless at exactly this enumeration, and at drafting the matching master data. The discipline is keeping generated scenarios tethered to your config: a beautifully complete matrix full of order types you don't use is noise with a header row.
Assemble the grounding pack. Three artifacts: the functional spec or change description, the relevant configuration facts (order types, item categories, payment terms, credit-control settings actually in use — export the real lists, per pb-44), and last quarter's defect log for the area. The defect log is the underrated one: it tells the generator where this system actually breaks.
Generate the scenario matrix with dimensions, then combinations.
You are designing regression tests for the order-to-cash flow in
our S/4HANA system after a change to credit management config.
Grounding (attached): functional spec for the change; our actual
order types (OR, ZOR, ZRUSH), payment terms list, credit risk
categories; defect log for O2C, last 2 quarters.
Step 1 — list the test dimensions and their values FROM THE
GROUNDING ONLY (no invented order types or terms).
Step 2 — propose a scenario matrix: full coverage on the two
dimensions the change touches (credit status × order type),
pairwise coverage elsewhere. Include the edge scenarios:
partial delivery then credit block, block released mid-flow,
foreign-currency order crossing a rate change, zero-value order,
and any scenario matching a defect-log pattern.
Step 3 — output as a table: ID, scenario name, dimension values,
preconditions, steps (numbered), expected result source
("spec §" or "config table" reference — never your own knowledge).
Review the dimension list before accepting combinations — a missing dimension (plant? partial payment?) invalidates the whole matrix, and only you know it's missing.
Prune like an engineer, not a collector. The generator will happily emit 200 scenarios. Keep full combination coverage only where the change lives; accept pairwise elsewhere; delete scenarios your config makes impossible (the model will propose a credit block on a cash sale — enjoy catching it, then delete it). A right-sized regression matrix for a scoped change is typically 30–60 scenarios, each earning its runtime.
Generate synthetic master data that honors config. For each distinct precondition set, draft the data spec:
For scenario IDs T-014..T-022 (attached), generate synthetic master
data specs honoring our config: customers (country, currency,
payment terms from our real list, credit risk category and limit),
materials (sales org/plant views consistent with order type ZOR,
base unit, price condition record values), and open items where a
precondition needs existing credit exposure.
All names/addresses/tax IDs must be plainly fictitious (use
"TESTCUST-nn" naming). Output as CSV per object type, columns
matching our LSMW/migration-cockpit templates (headers attached).
Load through your standard tooling (migration cockpit, LTMC/LSMW, test-data scripts, eCATT/CBTA where established). Data that arrives through the same door as real data inherits the system's validations — which is itself a test.
Dry-run two scenarios end-to-end before scaling. Execute one mainstream and one edge scenario manually. This validates the matrix's step quality, the data's loadability and — critically — the expected results against the actual system. Fix the generator's systematic errors now (wrong movement type in step 6 of every delivery scenario is one prompt fix, not thirty manual edits).
File the suite where tests live, tagged for reuse. Import scenarios into your test-management tool with the change reference, data-spec links and grounding-pack version. Next regression cycle starts from this matrix plus a delta prompt — which is the moment this stops being a one-off and becomes your team's compounding asset.
Never seed synthetic-data generation by pasting real customer or vendor records as "examples" — the generator will remix identifiable fragments into its output. Ground on config and templates, and keep production extracts out of the prompt entirely.
The model's edge is enumeration; yours is knowing which combinations are real. Ground the matrix in actual config, source expected results from outside the model, dry-run before scaling — and your regression suite finally covers the partial-delivery-credit-block-foreign-currency path that production has been testing for you.