Lesson 5 of 5
Testing master data
9 min
Contoso will load thousands of customers, products and customer-material records before go-live. Testing every one by hand is impossible, and testing none is reckless. The practical approach is to validate the data in bulk where you can, and to prove representative records with probe orders before scenario testing starts. A probe order is a sales order created only to see what master data defaults into it.
Why test master data first
If Priya's team starts order-to-cash scenario testing with unverified master data, every failure has two possible causes: the process configuration or the data. Testers lose days separating them. Proving the master data first means that when a scenario fails later, the data has already been ruled out.
- Choose the recordGreat Lakes Fleet Services with CMC-ALT-100 in sales area 1710 / 10 / 00
- Write expected defaultsPartners, plant, shipping point, item category, prices, tax, payment terms, incoterms
- Create the probe orderIn QAS client 100 with Create Sales Orders or VA01
- CompareEach defaulted value against the expected one
- Record and clean upSave evidence, then reject or delete the probe order so it does not enter delivery or reports
What a probe order checks
| Check | Where in the order | Master data source |
|---|---|---|
| Sold-to, ship-to, bill-to, payer | Header Partners tab | Customer partner functions |
| Delivering plant | Item | Customer-material info, customer, product |
| Shipping point and route | Item shipping data | Shipping conditions, loading group, plant, transportation group |
| Item category | Item | Product item category group |
| Prices and pricing procedure | Item conditions | Customer pricing procedure, price group, condition records |
| Tax | Item conditions | Customer and product tax classification, ship-to location |
| Payment terms and incoterms | Header billing data | Customer sales area billing data |
| Customer material number | Item | Customer-material info record |
A probe order checklist. Write the expected value for each line before creating the order.
Bulk validation
Probe orders prove that the data drives orders correctly. Bulk validation proves that the data is present and consistent. After each data load, the data migration team should compare record counts with the source, check mandatory fields per sales area (no customer without a customer pricing procedure, no product without an item category group in an active channel), and look for impossible combinations such as a ship-to without an address in the delivery country. Use the migration tool's own validation reports and simple list reports; the point is to catch missing data before a probe order finds it one record at a time.
- Is the value wrong in the master record itself?Yes → data defect; correct the record and check the load rule · No → next question
- Is a higher-priority source overriding it, such as a customer-material info record?Yes → decide which record is right · No → next question
- Does configuration determine it, such as partner or pricing procedure determination?Yes → configuration defect for the functional team · No → re-check the expected value
What would you do?
Data migration reports that all 2,300 customers loaded without errors. Priya wants to start order-to-cash scenarios tomorrow. Maria has run no probe orders. What is the best recommendation?
- Test master data before scenarios so later failures can be traced to process, not data.
- A probe order compares defaulted values with expected ones: partners, plant, shipping point, item category, prices, tax, terms.
- Probe by risk: every key account, one per pattern, and unusual records.
- Bulk validation checks counts, mandatory fields and impossible combinations after each load.
- Reject or delete probe orders after use.
Check your understanding · not graded
Lesson check
1. What is a probe order?
2. Why test sales master data before order-to-cash scenarios?
3. Which customers should always get individual probe orders?
4. Why reject or delete probe orders after use?