Lesson 4 of 6
Expected results that prove the business outcome
10 min
The expected result is the part of a scenario that turns an activity into a test. Without it, the tester can only report that something happened. With it, the tester can report whether what happened is right. This lesson is about writing expected results that a process owner like Dan can rely on when he signs.
Why "saved successfully" is not an expected result
"Sales order 1000457 has been saved" tells you a document exists. It does not tell you that the price was the fleet contract price, that the delivery date was confirmed, that the goods left the right plant, or that revenue posted to the right account. Most defects that reach production are of this kind: the system did something, quietly, but not the right thing. Expected results must be written so those defects fail the test.
Compute the numbers before you test
Expected values are worked out in advance, from the requirement and the master data, not read off the screen during the test. For Contoso's scenario O2C-010 the arithmetic is simple, and writing it down is what makes the test objective:
| Step | Expected result with values |
|---|---|
| Create sales order | Net price 240.00 USD per unit from the fleet contract; net value 12,000.00 USD for 50 units; schedule line confirmed for the requested date |
| Post goods issue | Stock of CMC-ALT-100 in plant 1710, storage location 171A falls by 50; journal entry debits cost of goods sold and credits finished goods inventory for 7,500.00 USD (50 × $150 standard cost) |
| Create billing document | Invoice for 50 units, net 12,000.00 USD plus tax per the customer's tax classification; billing document posted to accounting |
| Check journal entry for billing | Receivable on Great Lakes Fleet Services for the gross amount; revenue 12,000.00 USD to the product sales revenue account; profit center for alternators |
If the Chicago data row is run, the cost of goods sold changes to 7,800.00 USD (50 × $156). This is exactly the kind of difference a weak expected result ("goods issue posted") would never catch.
Expected results for things that should not happen
Some scenarios test that the system refuses something: an order over the credit limit is blocked, a delivery cannot be created while the approval is pending, an invoice with a large price variance is blocked for payment. Here the expected result is the refusal itself, stated precisely: "Order saved with credit status blocked; delivery creation not possible; order appears in the credit manager's worklist". A scenario that expects a block and gets a clean order has failed, even though nothing went wrong from the user's point of view.
Accounting results without being an accountant
Key users outside finance often hesitate to write accounting results. You do not need to know every account number. You need to know the business meaning of the posting (inventory goes down, cost of goods sold goes up), the amount (from your arithmetic) and the account or account group the finance team agreed. Ask the finance key user for a one-page posting guide per scope item and reuse it in every scenario.
What would you do?
During a dry run, a tester finds that the goods issue for 50 alternators from plant 1710 posted 7,800.00 USD to cost of goods sold. The scenario's expected result says 7,500.00 USD. The tester asks whether to mark it as passed "because the goods issue worked". What do you say?
- "Saved successfully" proves a document exists, not that the business outcome is right.
- Expected results move from system response to document content, status and flow, and accounting result.
- Compute expected values in advance from requirements and master data.
- For blocks and refusals, the refusal itself is the expected result.
- Ask finance for a posting guide so every key user can write accounting results.
Check your understanding · not graded
Lesson check
1. When should expected values such as prices and posting amounts be determined?
2. What is the expected cost of goods sold for 50 alternators issued from Detroit at a $150 standard cost?
3. A scenario tests that an order over the credit limit is blocked. The order saves with no block. What is the result?
4. Which expected result is strongest for a billing step?