Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 6 of 6

Master data as a test precondition

8 min

Ask any experienced SAP test lead what causes the most failed test runs, and the answer is rarely the code. It is the data. A process test that fails because the product had no sales view tells you nothing about whether the process works. Worse, it costs a defect triage meeting, a retest and a day of schedule. The fix is simple discipline: treat master data as a precondition that you verify before you execute.

Two kinds of master data failure

Loud, low impactMissing description translation. The test stops; easy to spot and fix.
Loud, high impactMissing sales view or customer role. Order cannot be created; blocks the whole scenario until fixed.
Silent, low impactWrong search term or old material number. Annoying, rarely affects money.
Silent, high impactWrong valuation class, payment terms or profit center. Everything saves; finance and reporting are wrong.
Master data risks by visibility and impact. The silent, high-impact quadrant needs the most attention.

Loud failures waste time. Silent failures are worse because they let a test pass when the business result is wrong. A tester who only checks that the document saved will pass a goods receipt that posted to the wrong inventory account.

A pre-test master data checklist

Before executing an order-to-cash, procure-to-pay or plan-to-produce test, confirm the data it needs. For Contoso's sell-from-stock test of CMC-ALT-100 in sales area 1710 / 10 / 00 from plant 1710:

  1. Customer: business partner has the customer roles, company code 1710 data (reconciliation account, payment terms) and sales area 1710 / 10 / 00 data (shipping conditions, incoterms, partner functions).
  2. Product: basic data, sales views for 1710 / 10, plant and MRP views for 1710, accounting view with a valuation class and a price.
  3. Price: a valid base price condition record for today (and for any posting date the test uses).
  4. Stock: enough unrestricted stock in plant 1710 and the expected storage location.
  5. Finance: the profit center on the product plant view is valid; revenue and cost of goods sold accounts exist for company code 1710.
  6. Expected values: write down what the result should be (price, tax, accounts, profit center) before you run, so you can compare afterwards.

How to check quickly

You do not need special tools. Display the business partner in transaction BP or the customer app and step through the roles. Display the product in MM03 or Manage Product Master Data and select the plant and sales area you will test. Check stock with the Stock - Single Material app or MMBE. Check the price by creating a test order and simulating, or by displaying the condition record. Many teams turn this into a short data sheet attached to each test case so the next tester inherits it.

  1. Does the test fail at document creation with an "not defined" or "not maintained" message?Yes → check the master record for that org unit (sales area, plant, company code) · No → continue
  2. Did the document save but a value looks wrong?Yes → compare the value against the master record it was copied from · No → continue
  3. Does the master record hold the right value?Yes → suspect configuration (determination rules) and log a process defect · No → log a master data defect and fix the record
  4. Has the fix been made?Yes → rerun the full scenario, not just the failed step · No → mark the test blocked, not failed
Triage path for a failure that might be master data.

Master data in a release

Master data also changes between releases: new plants, new product types, new roles, mass changes. Treat a master data change as a change to test. When Contoso opens the Chicago plant for sales, the sales views, plant views, prices and stock for 1720 are as much a part of the release as any configuration. A key user signing off that release should see evidence that a sample of those records was checked, not just that the load program ran without errors.

What would you do?

Halfway through a test cycle, 14 of Contoso's 40 order-to-cash tests have failed. Eleven failures show "product not defined for sales area" for products loaded last week. The project manager asks whether the order-to-cash process can be signed off. What do you recommend?

Key points
  • Verify master data before execution so failures point to the process, not the setup.
  • Silent, high-impact errors (valuation class, payment terms, profit center) are the most dangerous.
  • Write expected values down before you run the test.
  • Tag failures by cause and rerun full scenarios after a data fix.
  • Master data changes are part of a release and need their own evidence.

Check your understanding · not graded

Lesson check

  1. 1. Why are silent master data errors more dangerous than loud ones?

  2. 2. After a master data defect is fixed, what should be rerun?

  3. 3. What should a tester write down before executing a scenario?

  4. 4. A test stops because the product is not maintained in plant 1720. How should the result be recorded?