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

Lesson 1 of 5

What data a scenario needs

9 min

Ask testers why a UAT day went badly and the answer is rarely "the system was broken". More often it is "the customer wasn't set up for that sales area", "there was no stock" or "someone else used my order". Test data is the most underestimated part of business testing. This course teaches you to plan it as carefully as the steps.

Start by breaking every scenario into three kinds of data. They come from different places, have different owners and fail in different ways.

Configuration valuesOrg units and settings the scenario relies on: company code 1710, plant 1710, sales area 1710 / 10 / 00, order types, pricing procedures. Delivered by transport; testers do not create them.
Master dataLong-lived records: business partners as customers and suppliers, products, pricing conditions, bills of material, G/L accounts, cost and profit centers. Created once, used by many transactions.
Transactional preconditionsWhat must already have happened: stock on hand, open receivables, an approved credit limit, a released purchase order, an open posting period.
Three layers of test data. Each scenario needs all three to be right.
The Sign-Off Table · thesignofftable.com/academy/sap-bku-204

Working through an order-to-cash example

Take Contoso's scenario O2C-010: sell 50 alternators CMC-ALT-100 from plant 1710 to Great Lakes Fleet Services at contract price. Walk through the steps and ask, for each, "what has to exist for this step to work and give the expected result?"

StepConfiguration it relies onMaster data it needsPreconditions
Create sales orderSales area 1710 / 10 / 00; standard order type; pricing procedureBusiness partner with customer role extended to the sales area; product with sales views; contract price condition recordCredit limit high enough for 12,000 USD plus existing exposure
Create deliveryShipping point 1710; delivery typeProduct with plant data for 1710; ship-to addressOrder not blocked; requested date reached or within the selection window
Pick and post goods issueStorage location 171A; movement type for goods issueProduct valuation data (standard price $150)50 or more units unrestricted in 1710 / 171A; materials management period open
Create billing documentBilling type; revenue account determinationCustomer tax classification and payment termsDelivery with goods issue posted; financial posting period open
Data needed by O2C-010, step by step.
The Sign-Off Table · thesignofftable.com/academy/sap-bku-204

Some needs are obvious (stock). Others only appear when you think about the expected result. The scenario expects the fleet contract price, so a pricing condition record for that customer and product must exist and be valid on the order date. It expects revenue on the alternator profit center, so the product must carry the right profit center in its plant data. Each expected result points at data that must be correct.

A data needs checklist

  • Who: which business partners (customer, supplier, bank) and in which roles and org units.
  • What: which products, in which plants and storage locations, with which views.
  • At what price: condition records, contracts, info records, valid on the test dates.
  • What already exists: stock, open items, open orders, approved limits.
  • When: which posting dates and periods, and whether those periods are open.
  • Who does it: which test users with which business roles.

Who provides each layer

The three layers also have different owners, and knowing them saves days of chasing. Configuration belongs to the solution team and arrives by transport: if a sales area or order type is missing, that is a build or transport issue, not something a tester fixes. Master data usually has a business owner (sales operations for customers, product management for products, finance for G/L accounts and profit centers) and on a project is often loaded by the data migration team. Transactional preconditions are normally created by the key users themselves, following a setup script. When a scenario fails for want of data, the layer tells you whom to call.

Write the data needs into the scenario's preconditions section in this order, configuration first. A tester who reads "sales area 1710 / 10 / 00 must exist" and finds it missing knows immediately that the problem is upstream and stops before wasting an hour on a step that cannot work.

What would you do?

Maria runs O2C-010 and the order shows the list price, not the fleet contract price. The customer and product exist. What is the most likely data problem?

Key points
  • Split every scenario's data into configuration, master data and transactional preconditions.
  • Walk the steps and ask what must exist for each step and its expected result.
  • Expected results reveal hidden data needs such as condition records and profit centers.
  • Include dates, periods and test users in the data plan.

Check your understanding · not graded

Lesson check

  1. 1. Which item is master data rather than a transactional precondition?

  2. 2. Who normally delivers configuration values such as sales areas and order types to the test system?

  3. 3. The expected result requires revenue on the alternator profit center. Which data must be right?

  4. 4. Which precondition is needed before testing goods issue for a stocked product?