Lesson 2 of 6
Executing and recording
8 min
Execution sounds simple: follow the steps, see what happens. The discipline is in two habits. First, follow the steps as written, so the result tests what the case was designed to test. Second, record what actually happened, in facts another person can check, before you judge it.
- Read the stepKnow the action, the data and the expected result before you touch the system
- Perform it exactlyUse the app or transaction and data the step names; note any deviation
- Record the actual resultMessages with type and number, document numbers, values, statuses
- Compare with expectedMatch → pass the step · Mismatch → fail it · Could not do it → blocked
- Capture evidenceAt the checkpoints the case asks for, and whenever something unexpected happens
Record facts, not feelings
"Didn't work" is not an actual result. "Error message V1 801: Pricing error: mandatory condition PR00 is missing" is. "Order saved fine" is not either. "Standard Order 1000457 has been saved; net value 7,500.00 USD; delivery date 07/18" is. Write down message texts with their type (error, warning, success, information) and, where shown, the message class and number. In SAP GUI, double-clicking a message or using the performance assistant shows the long text and technical details; in Fiori apps, the message popover usually offers details. Record every document number the step creates.
| Status | Meaning | Example |
|---|---|---|
| Passed | The actual result matches the expected result | Order created at the expected price, tax and delivery date |
| Failed | The step ran, but the actual result differs from the expected result | Order created, but the price is 165.00 instead of 150.00 per piece |
| Blocked | The step could not be executed because of something outside the step | No stock in plant 1710; the transport with the fix is not imported; your user is locked |
| Not run / In progress | Not started yet, or started and not finished | Tester ran steps 1–4 and will continue tomorrow |
Failed or blocked?
The distinction matters for reporting. A failure says the system does something wrong; it needs a defect and a fix. A blocked step says the test could not be performed; it needs an obstacle removed. If step 3 fails and steps 4–9 depend on it, mark step 3 failed and the rest blocked, with a reference to the defect. Reporting all of them as failed inflates the defect picture; reporting them as passed is simply untrue.
When the steps are wrong
Sometimes the test case is the problem: an app name changed, a field no longer exists, the expected result was written against ECC behavior. Do not quietly improvise. Record what you did instead and why, and flag the case for correction. If the expected result is wrong, the step is neither passed nor failed until the process owner confirms the right result. Contoso tracks these as test-case defects so they are fixed for the regression set too.
Also note observations outside the script. If you notice the delivery date proposal looks odd, or a warning appears that nobody mentioned, write it down even if the step passes. Experienced key users find many valuable defects this way, because they know what normal looks like.
What would you do?
Priya's tester reaches step 6 of an order-to-cash case: create billing document. The billing document saves, but the success message says the document "has been saved (accounting document not created)". The expected result says "billing document posted to accounting". What is the correct record?
- Follow steps exactly; record any deviation and why.
- Record facts: message type and number, document numbers, values and statuses.
- Passed means actual equals expected; failed means it ran and differed; blocked means it could not run.
- Record failures before using a workaround, and flag wrong test cases for correction.
Check your understanding · not graded
Lesson check
1. Which is a usable actual result?
2. Step 3 fails and steps 4–9 depend on it. How are steps 4–9 marked?
3. You continue past a failed step by entering a price manually. What must you do first?
4. The test case names an app that no longer exists in the release. What do you do?