Lesson 2 of 5
Planning data per scenario
9 min
Listen to this lesson
A test data plan answers three questions for every scenario: what data does it need, what does it use up, and how will that data be replenished for the next run? Write it down before the cycle starts. Discovering on day two of user acceptance testing that there is no stock of CMC-RTR-200 in Chicago costs far more than an hour of planning.
Start from the scenario, not the system
Work through each test case step by step and list every object it touches. For Contoso's sell-from-stock scenario, that list includes the sales area, the sold-to and ship-to business partner Great Lakes Fleet Services with sales area data, the product CMC-ALT-100 with sales and plant views for 1710, a valid price condition, stock in storage location 171A, a credit limit high enough to avoid a block, and an open posting period. Each item is either already there, needs to be created, or needs to be posted.
| Data item | Type | Consumed? | Source | Replenishment |
|---|---|---|---|---|
| Customer Great Lakes Fleet Services (sales area 1710 / 10 / 00) | Master | No, but credit exposure grows | Migrated | Reset credit exposure or raise limit for test |
| Product CMC-ALT-100, plant 1710 | Master | No | Migrated | None needed |
| Price condition for CMC-ALT-100 | Master (condition) | No, but has a validity period | Created by pricing team | Extend validity before each cycle |
| Stock: 50 pieces in 171A | Transactional (balance) | Yes | Initial stock posting | Post receipt or production before each run |
| Open sales order for delivery test | Transactional | Yes | Created by step 1 | Recreated each run |
Part of a data plan for Contoso's sell-from-stock scenario.
Consumption and replenishment
Some data is used up by a single execution. Stock is the obvious example, but there are others: an open purchase order that a goods receipt test fully receives, a supplier invoice that a payment run clears, or a credit limit that fills up after a dozen orders. For every item that gets used up, decide how it will be replenished: posted by a setup step, created by a preceding test, or provided in bulk at the start of the cycle with enough headroom for retests.
- IdentifyList every object each scenario step reads or changes
- ClassifyConfiguration, organizational, master or transactional; consumed or not
- SourceExists already, create it, migrate it, or post it
- ReserveAssign data sets to testers or automated runs so they do not collide
- ReplenishPlan setup steps or bulk loads with headroom for retests
- VerifyCheck data readiness before the cycle opens, not on day one
Reserving data for parallel testers
When twenty testers and a set of automated regression runs share QAS client 100, they will collide. One tester's goods issue uses the stock another tester counted on. An automated test changes the payment terms on a customer that a manual tester is using. The fix is to partition the data: give each tester or run its own customers, products or storage locations, or at least its own clearly labeled set.
- Create a small block of test customers per team, for example one ship-to per tester under Great Lakes Fleet Services.
- Keep automated regression data separate from manual testing data, so a rerun at night does not break a test someone is halfway through.
- Use a naming or search-term convention so anyone can see who owns a record.
- Record the reservation in the test management tool next to the test case, not in a private spreadsheet.
| Aspect | Shared data pool | Partitioned data sets |
|---|---|---|
| Who uses CMC-RTR-200 in 171A | Every tester and the nightly automated run | Each tester or run has its own product, ship-to or storage location |
| Typical morning | "Deficit of stock" failures from someone else's goods issue | Each set holds what its owner planned |
| Ownership | Unclear; nobody knows who changed a record | Visible through a naming or search-term convention |
| Automated reruns | Break manual tests halfway through | Run on separate data and create what they consume |
Automated tests need an extra rule: they should create or reset what they consume. A regression test that expects a fresh open purchase order should create one in its first step, not hope that one is lying around. Tests that depend on yesterday's leftovers are the main cause of flaky automation in SAP, and they fail in ways that look like system defects.
What would you do?
During Contoso's integration test cycle, three testers and a nightly automated regression all use product CMC-RTR-200 in storage location 171A. Every morning several manual tests fail with "deficit of stock". What is the best fix?
- Plan data per scenario by listing every object each step reads or changes.
- Mark data that tests use up and decide how it is replenished before the cycle starts.
- Partition data between testers and automated runs to avoid collisions.
- Check validity dates and open periods as part of data readiness.
Check your understanding · not graded
Lesson check
1. Which data item is consumed by a single run of a sell-from-stock test?
2. Why partition data between parallel testers?
3. A test that passed in March fails in June with "no price found". What is a likely data cause?
4. Where should data reservations be recorded?