Kinds of review
In short: A review has five steps: planning, initiation, individual review, communication and analysis, and fixing and reporting. The roles are author, reviewers, moderator, scribe, review leader and manager. The kinds differ in formality: informal, walkthrough, technical review and inspection. The checklist says what to look for, and the document is reviewed, not the author.
Problem
"We reviewed it"
The returns specification is ready. The analyst brings it to the Monday meeting. Six people see it for the first time on the screen. Someone asks about the font, two argue about how it will be stored in the database, the owner says "looks good". An hour later the meeting is over. Nobody wrote anything down.
Two weeks later it turns out that "14 days" counts from the order, while the law counts from receipt. Everyone was at the meeting. Nobody read the text.
The meeting was not a review. It was people gathered around a document.
The idea
The five steps
A real review has a process. In ISTQB CTFL it has five steps:
- Planning. What is reviewed, for what purpose, by whom, by when, with which checklist, and when the review is finished.
- Initiation. Everyone gets the document and knows their role and what to look for.
- Individual review. Everyone reads alone, before the meeting, and writes down their findings. This is where most is found.
- Communication and analysis. The findings are discussed together. For each one: is it a problem, how important is it, who fixes it.
- Fixing and reporting. The author fixes. The findings and the decision are recorded: is the document accepted, or does it need another review.
The Monday meeting was only step 4, without 1, 2 and 3. That is why it talked about the font.
More precisely, if you are curious
CTFL v4.0.1 (section 3.2) describes the work product review process, referring to the standard ISO/IEC 20246. How much of the process is followed depends on the kind of review: an informal one may skip almost all of it, an inspection follows it completely.
Try it
Order the process
Order the steps of the review.
Initiation: everyone gets the document and knows their roleFixing and reporting: the author fixes, and the decision and findings are recordedPlanning: what is reviewed, by whom, by when, with which checklistCommunication and analysis: the findings are discussed together and decisions are madeIndividual review: everyone reads alone and writes down their findings
If the reviewers read only at the meeting, step 3 is skipped and step 4 turns into reading aloud. If nobody writes anything down, step 5 does not exist.
The idea
Who does what
| Role | What they do | In the returns review |
|---|---|---|
| author | created the document and fixes it | the analyst |
| manager | decides what is reviewed, provides people and time | the team lead |
| moderator (facilitator) | runs the meeting, guards the time and the tone | someone neutral, not the author |
| scribe | records the findings and decisions | someone from the team |
| reviewer | reads and finds problems | QA, a developer, the warehouse, the owner |
| review leader | is responsible for the review as a whole: who takes part, when, where | often the same as the moderator |
In a small team one person has several roles. What matters is that the roles exist, not that there are six people.
Reviewers are most useful when they look from different places. The warehouse will ask "who receives the returned product?". Accounting will ask "when is the money refunded?". QA will ask "and on day 14?".
Try it
Whose role is it?
The idea
The four kinds
Reviews differ in how formal they are. The riskier the document, the more formality is worth it.
| Kind | Who leads | Goal | In the shop |
|---|---|---|---|
| informal review | nobody; no process | find problems, quickly | "take a quick look at the criteria" |
| walkthrough | the author | find problems, have people understand the document and agree | the analyst walks the warehouse through the returns specification |
| technical review | a moderator | consensus and a decision on a technical question | how discounts are calculated |
| inspection | a trained moderator | find as many problems as possible; metrics improve the process | the payment specification |
An informal review is not bad. It is the most common and the cheapest. But when a mistake costs customers money, as with payment, the full process is worth it.
More precisely, if you are curious
In CTFL v4.0.1 the inspection is the only kind where the process is followed completely and metrics are collected. There the author cannot act as the review leader or the scribe. The kind is chosen by the goal, the risk, the team's culture and the requirements of the domain: in regulated fields (medicine, transport) inspections are often mandatory.
Try it
Which kind is it?
The idea
The checklist
A reviewer who reads "to see if everything is fine" sees little. One who has questions sees a lot. A checklist is a list of questions asked of every document of one kind.
A checklist for requirements in the shop:
- Does it say who (customer, employee, any visitor)?
- Is there a measure instead of "fast", "convenient", "clear"?
- Is it clear what happens at the boundary (50.00 €, day 14, the 10th item)?
- Does it say what happens in the negative case (cancellation, error, expired code)?
- Is there a closed list instead of "etc."?
- Does it say what, not how?
- Does it contradict another requirement?
The checklist is alive. Every time a defect slips through a review, the team asks "which question would have caught it?" and adds it.
And one rule about tone: the document is reviewed, not the author. "The boundary is not clear here", not "you did not think about the boundary". A review where someone is put on trial is not repeated willingly.
More precisely, if you are curious
CTFL v4.0.1 also lists what makes reviews successful: clear objectives and exit criteria; the right kind for the goal; small chunks, so the reviewers do not tire; enough time to prepare; support from management; a culture where a review is for learning, not for punishment. Besides checklists there are other ways of reading: scenario-based (the reviewer walks the document through a concrete use) and perspective-based (one reads as a customer, another as a tester, a third as the warehouse).
Exercise
A review with a checklist
1. Which question catches it? For each requirement, choose the checklist question that finds the problem.
Test