Expected results that prove something

An expected result is the line in a test case that turns an activity into a test. Without it, the tester is only operating the system. With a weak one, the tester decides on the spot what "correct" means, and two testers reach two verdicts. A strong expected result is observable, specific and written before execution, so the comparison is mechanical. The test of a good expected result is simple: two testers who have never met should read it, look at the same screen, and record the same verdict. Here is the same step written three ways, weak, better and strong, from Contoso's order-to-cash case using variant A: Great Lakes Fleet Services orders 50 alternators CMC-ALT-100 at a contract price of 240.00 USD each.

"No errors" and "saved successfully" prove only that the system accepted the input. SAP will happily save an order with the wrong price, the wrong ship-to party or a forgotten item. The strong versions check what the business cares about: values, statuses, follow-on documents and postings. They are longer, but each clause is something the tester can look at and tick, and each one would catch a real class of defect: a missing price condition, an incomplete order, a wrong account, a missing profit center. The layers below are a useful way to decide what to check.

Not every step needs every layer. A message check is still worth keeping where the message itself is the requirement, such as a warning a user must see before releasing a blocked order, but it should never be the only check on a step that creates business value. Intermediate steps often need one or two checks, while the last step of a scenario should confirm the end state: the full document flow and the financial result. Put the heavy checks where the business risk is. Tie each check to the evidence the tester captures: if the expected result names the journal entry, the evidence list should say "display of the journal entry for BILLING_NO", so the reviewer can see the same values the tester compared. The document flow is usually the best single piece of evidence for the end state, because it shows every successor and its status on one screen.

State the rule, not only the number

Values change between cycles: prices are updated, tax rates move, standard costs are re-rolled. If the expected result only says "12,000.00", it breaks the moment the price record changes. Write the rule and keep the computed value in the data sheet: "net value equals quantity times the customer contract price in DS-O2C-01". The tester checks the number; the reviewer can check the rule. This is the expected-result version of separating data from steps. Also name the source of truth where it is not obvious. For a price, it is the condition record or the contract. For an account, it is the account determination in the design document. For a tax amount, it is the tax code and jurisdiction in the data set. If the expected result is "whatever the system shows", it is not an expected result.

Negative and blocking results

Some of the most valuable SAP tests expect the system to say no. A customer over its credit limit should block delivery; a supplier invoice above tolerance should be blocked for payment; a user without the right role should not be able to release an order. Write these with the same precision: which message type or status, on which document, and what must not exist afterwards (for example, no delivery for the blocked order). Avoid quoting full message texts word for word, because wording can change with a support pack; name the condition instead ("an error stops the save because the credit limit is exceeded") and record the actual message in the evidence. A negative test that passes for the wrong reason, such as a missing authorization instead of the credit block, is a false pass, so say which reason you expect.