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

Lesson 6 of 6

Test cases

10 min

Contoso's sales order tests have one job: prove that orders behave as the business expects in the situations that actually happen. Saving an order proves very little. The value is in partial availability, incompletion, blocks and multi-item behavior, and in evidence that shows statuses, schedule lines and document flow, not just a success message.

A sales order test set

IDScenarioSetupExpected result
SO-01Standard multi-item order, full availability50 × CMC-ALT-100 and 20 × CMC-RTR-200, stock available in 1710Both items confirmed on requested date; correct prices, plant, item category; complete
SO-02Partial availability, partial delivery allowedOnly 30 alternators in stock; 40 due from productionTwo schedule lines: 30 on requested date, 20 later
SO-03Partial availability, complete delivery requiredSame stock; complete delivery set50 confirmed together on the later date
SO-04No availabilityZero stock, no receipts in horizonNo confirmed quantity; order appears in monitoring as not confirmed
SO-05Incomplete orderSave without incoterms locationLog lists the field; order not in delivery due list; completing it opens delivery
SO-06Delivery block set and releasedBlock 'address check' set by salesNot in due list; unauthorized user cannot release; authorized release opens delivery
SO-07Billing block on itemBlock 'price check' on item 10Delivery and goods issue proceed; item not in billing due list until released by pricing
SO-08Credit blockOrder exceeds the test customer's credit limitCredit status blocked; sales cannot release; credit controller releases
SO-09Duplicate customer referenceReuse an existing customer PO numberWarning shown as configured
SO-10Order change after confirmationIncrease quantity from 50 to 60Availability rechecked; new schedule line for the extra 10 as stock allows

Contoso's core sales order test cases. Quantities and settings are examples.

Spot checkRare, low impact: unusual units of measure
Test once, carefullyRare, high impact: credit block release, complete delivery for key fleet accounts
Include in regressionFrequent, low impact: duplicate reference warning
Test thoroughly and automate in regressionFrequent, high impact: partial availability, multi-item orders, billing blocks
Choosing which sales order variants to test deeply.
The Sign-Off Table · thesignofftable.com/academy/sap-sd-202

Evidence that proves the result

Order numberProves an order exists; nothing more
Item detailsPlant, item category, net price and conditions match expected values
Schedule linesRequested and confirmed quantities and dates match the expected availability result
StatusesCompleteness, delivery block, billing block and credit status before and after each action
Document flowDelivery and billing exist or do not exist as expected, proving the effect on follow-on steps
What evidence each sales order test needs, from weakest to strongest.
The Sign-Off Table · thesignofftable.com/academy/sap-sd-202

For block and incompletion tests, the strongest evidence is a before-and-after pair: the status and due list before the action, and after it. A block test that shows only the block reason on the order proves the block was set, not that it stopped anything.

Test data for availability

Availability tests are only as good as their stock setup. Before SO-02 to SO-04, set known stock in plant 1710 (for example by a test goods receipt) and known receipts (a planned production order for 40 units due on a known date), and record them. Then the expected schedule lines are predictable. Running availability tests on whatever stock happens to be in QAS produces results nobody can judge.

  1. Day 1 morningSet stock and receiptsPost 30 units into storage location 171A; create a production order for 40 due on the 20th
  2. Day 1 middayRun SO-02 and SO-03Check schedule lines against the expected 30/20 split and the complete delivery date
  3. Day 1 afternoonRun SO-04 on a product with no stockCheck no confirmation and the monitoring app entry
  4. Day 1 endClean upReject test orders so later cycles start from known stock
Running Contoso's availability tests in one test cycle.
The Sign-Off Table · thesignofftable.com/academy/sap-sd-202

What would you do?

A tester reports SO-06 (delivery block) as passed with a screenshot of the order header showing the block reason. Priya reviews the evidence. What should she ask for?

Key points
  • Test the situations that matter: multi-item, partial and no availability, incompletion, blocks, credit, changes.
  • Rank variants by frequency and impact; test high-impact ones thoroughly and keep them in regression.
  • Evidence: item details, schedule lines, statuses before and after, and document flow.
  • Set known stock and receipts before availability tests so expected results are predictable.
  • Block tests must prove set, stop, unauthorized release refused and authorized release.

Check your understanding · not graded

Lesson check

  1. 1. Which evidence best proves a delivery block works?

  2. 2. Why set known stock and receipts before availability tests?

  3. 3. Which variant belongs in 'test thoroughly and automate in regression' for Contoso?

  4. 4. A quantity is increased on a confirmed order. What should the test expect?