Lesson 6 of 6
Peer review
10 min
Scenarios are written by people who know the process well, which is both their strength and their weakness. The author knows what "check the price" means; the tester running it next month may not. A short peer review, done before execution, catches most of these gaps for the cost of an hour.
The review checklist
| Criterion | Question the reviewer asks | Typical finding |
|---|---|---|
| Clarity | Could a colleague from another team run this without asking the author? | Step says "post it" without naming the app or the document |
| Preconditions | Is everything that must exist before step 1 listed? | Stock in storage location 171A not mentioned |
| Data independence | Does the scenario use its own data, or data another tester will change? | Uses the same customer as the credit block scenario |
| Verifiability | Does every step with a business effect have a checkable expected result? | "Billing works" instead of values |
| Accounting | Are journal entries stated where the step posts? | Goods issue result omits cost of goods sold |
| Traceability | Are scope item, process step and requirement IDs recorded? | No requirement ID |
| Negative and variant coverage | Are the important "should not happen" cases covered somewhere? | Approval rejection not tested |
| Evidence | Does the scenario say what to capture? | No instruction to record document numbers |
A peer review checklist for business test scenarios.
How to run a review
- Can you run it on paper without asking the author?Yes → check data · No → mark unclear steps and return
- Is the data independent and are preconditions complete?Yes → check results · No → assign own data range or add preconditions
- Is every expected result checkable with values?Yes → check links · No → return with the steps that need values
- Are requirement and scope item links present?Yes → approve for execution · No → add links, then approve
Review on paper first: read each step and imagine doing it. Where you hesitate, the tester will too. Then look at the data: is it the scenario's own, and is everything set up? Then the expected results. Finally the links. Keep comments specific ("step 5: add expected net value") so the author can fix them quickly.
Practice: two scenarios
Here are two short extracts written by Contoso key users. Review them before you look at the scenario questions below.
| Extract | Text | Review comments |
|---|---|---|
| A: P2P-020 step 4 | "Post the invoice. Expected: invoice posted." | Name the app (Create Supplier Invoice or MIRO); give invoice amount and reference; expected result should state the journal entry (debit GR/IR, credit Lakeside Components, with tax) and that the invoice is not blocked for payment |
| B: O2C-030 preconditions | "Use customer Great Lakes Fleet Services. Make sure it has a credit limit." | This customer is shared with O2C-010 and the credit scenario will block it; assign a dedicated test customer and state the exact credit limit value and segment |
What would you do?
You are reviewing Luis's cutover rehearsal scenario. Step 7 reads "Check that open sales orders were migrated correctly. Expected: they look right." What is the best review comment?
What would you do?
Two key users disagree in a review. One says each scenario must contain the full BD9 step list even when only billing changed; the other wants a short billing-only scenario. What is the best guidance?
- Review scenarios before execution; it is cheap and catches most gaps.
- Check clarity, preconditions, data independence, verifiability, accounting, traceability, negatives and evidence.
- Read on paper: where you hesitate, the tester will too.
- Record reviewer, date and status so sign-off can rely on the scenarios.
Check your understanding · not graded
Lesson check
1. What is the first review question?
2. A scenario uses the same customer as a credit-block scenario. Which criterion does it fail?
3. What should a review comment on "Expected: invoice posted" ask for?
4. Why record reviewer, date and status for each scenario?