Lesson 6 of 6
Reviewing test cases
7 min
Listen to this lesson
A test case is a work product, and like a specification or a configuration design it can contain defects. Finding them by reading, before anyone runs the case, is static testing. The ISTQB Foundation syllabus treats reviews as a core quality activity because a defect found on paper is cheaper to fix than one found in the middle of a test cycle, when twenty testers are blocked or, worse, have passed a case that could never fail. Reviews also spread knowledge: a key user who reviews a consultant's case learns how the system will behave, and the consultant learns how the business really works. ISTQB describes a range of review types, from informal to formal, and on an SAP project you will use most of them. Match the formality to the risk of the process, not to the seniority of the author.
| Review type | How it runs | Good SAP use |
|---|---|---|
| Informal review | A colleague reads the case and comments; no fixed process | Quick peer check of a new block before it goes into a script |
| Walkthrough | The author walks the reviewers through the case | Explaining a complex scenario to key users so they can challenge the steps |
| Technical review | Peers check against standards and the design | Consultants checking expected postings against the account determination design |
| Inspection | Formal: roles, checklist, logged findings, follow-up | High-risk cases such as financial close or regulatory output before sign-off |
Review types and where they fit on an SAP program.
A review checklist
A checklist keeps reviews consistent between reviewers and turns opinions into findings. Who reviews matters as much as the checklist. Ask a tester who did not write the case to check runnability, and ask the process owner (Dan for finance, Maria for order-to-cash) to check that the expected results match what the business would accept. Contoso's checklist mirrors the lessons in this course:
- Objective states one business outcome; title matches the objective.
- Traceability links to the process step and requirement are present and current.
- Preconditions are checkable and complete (system, client, role, master data, stock, periods, upstream cases).
- No hard-coded document or master data numbers in steps; data comes from a named data set and variant.
- Runtime values are named and passed between steps.
- Every expected result could fail; it checks content, status, follow-on documents or postings, not only messages.
- Values are stated as a rule with the computed value in the data set; the source of truth is named.
- Level of detail fits the realistic reader; entry points are separate from step text.
- Waits for jobs or output are explicit; postconditions and cleanup are stated.
- Evidence to capture is listed; owner, version and review status are filled in.
Then log what you find. Record each finding against the checklist so the author can act on it without a meeting: where it is, which checklist item it breaks, how serious it is and a suggested fix. Write findings about the case, never about the author, and keep them short and concrete; "step 4 expected result cannot fail" is useful, "unclear" is not. In SAP Cloud ALM or SAP Solution Manager, keep the findings with the test case or in a linked review record, and do not set the case to its ready status until the findings are closed. Severity can be simple. A major finding means the case could give a wrong verdict or cannot be run; a minor finding makes it harder to run or maintain. Keep findings about the case separate from defects in the system: if a reviewer notices that the design itself looks wrong, that goes to the design owner as a question, not into the case's findings log. Here is a short excerpt Maria submitted for review, followed by Priya's findings.
| ID | Location | Checklist item | Severity | Finding and suggested fix |
|---|---|---|---|---|
| F1 | Precondition | 3 | Minor | Not checkable. State the data set and that the customer has sales area data for 1710 / 10 / 00 and no credit block. |
| F2 | Step 2 | 4 | Major | Hard-coded order 1000457 will not exist after refresh. Create the order in step 1 and pass ORDER_NO. |
| F3 | Step 4 | 6 | Major | Expected result cannot fail. Check goods movement status, stock drop of 30 and the COGS posting. |
| F4 | Step 5 | 6, 7 | Major | "Looks right" is not verifiable. State net value as 30 × contract price and the revenue posting. |
| F5 | Header | 10 | Minor | No evidence list or version. Add document numbers, document flow and journal entry as evidence. |
Findings logged against the sample. The author fixes, the reviewer verifies, then the case is approved.
- PlanChoose cases by risk; assign reviewers and the checklist
- Individual reviewEach reviewer reads against the checklist and logs findings
- DiscussAgree severity and fixes for major findings
- FixAuthor updates the case and raises the version
- Verify and approveReviewer confirms fixes; status set to approved or Prepared
Track review metrics lightly: how many cases reviewed, major findings per case, and how many reached execution still carrying major findings. If the last number is not near zero, the review step is being skipped under schedule pressure, and that is a risk to raise with the PMO. Watch the pattern of findings as well as the count. If most major findings are hard-coded data, the authors need a data sheet template; if most are weak expected results, a short session with the process owners on what they would check will fix more cases than any number of reviews. At sign-off, the test lead should be able to state how many executed cases were reviewed and approved, so the process owner knows how much weight the pass rate can bear.
- Are cases reaching execution with open major findings?Yes → reviews are being skipped; raise the risk with the PMO · No → continue
- Are most major findings hard-coded data?Yes → give authors a data sheet template · No → continue
- Are most major findings weak expected results?Yes → hold a short session with Dan and Maria on what they would check · No → keep reviewing by risk
What would you do?
It is two days before system integration test cycle 2. Grace, the PMO lead, proposes skipping reviews of the 80 new cases to protect the schedule. Priya has two reviewers available. What is the best plan?
- Reviewing test cases is static testing: finding defects in the case before it is run.
- Use informal reviews, walkthroughs, technical reviews and inspections according to risk.
- A checklist turns opinions into findings; log location, checklist item, severity and suggested fix.
- Track cases that reach execution with open major findings, and make that risk visible at sign-off.
Check your understanding · not graded
Lesson check
1. What is static testing?
2. Which review type is most formal, with defined roles, a checklist and follow-up?
3. A step says "Expected: invoice looks right". Which checklist item does this break?
4. Why should authors not be the only reviewers of their own cases?