3.4 Review Types

Choosing the Right Review Type

Review formality should fit the risk, work product, culture, regulation, and objective. A minor wording change in an internal wiki may need only an informal review; a safety-critical interface specification may need an inspection with defined roles, metrics, and documented follow-up. The CTFL v4.0 syllabus describes four review types, from least to most formal.

Informal review. It does not follow a defined process and does not require formal documented output. Its main aim is to detect anomalies quickly with low overhead. Examples: pair-checking a user story, a developer asking a colleague to glance over a small change, or a tester asking a product owner to confirm an acceptance criterion. Speed and low cost are the point.

Walkthrough. A walkthrough is usually led by the author, who presents the work product and guides participants through it. Beyond detecting anomalies, walkthroughs can educate reviewers, build shared understanding, reach consensus, generate new ideas, motivate and enable the author to improve, and consider alternatives. Individual preparation may occur but is optional, and a scribe is often used.

Technical review. Performed by technically qualified reviewers and usually led by a moderator. Its objectives include gaining consensus and making decisions, but also detecting anomalies, evaluating quality, building confidence, generating new ideas, and motivating authors. Individual preparation is part of it. Example: architects and senior developers reviewing a service-interface design before teams commit to building against it.

Inspection. The most formal review type. It follows the full generic review process, uses defined roles, collects metrics (for improving the software, the documents, and the process itself), and aims to find the maximum number of anomalies. It uses entry and exit criteria, and the author may not act as review leader or scribe, preserving objectivity. Inspections also explicitly support process improvement through their metrics.

Comparing the Four Types

The table summarises the strong signals examiners use to point at each review type. Memorise the signal words rather than the size of the document — the same document can be reviewed using different types at different times.

Key distinctions the exam loves:

• Author-led is the giveaway for a walkthrough.
• Technically qualified reviewers is the giveaway for a technical review.
• Metrics, maximum anomalies, full process, role discipline, audit trail point to an inspection.
• No documented output, no defined process points to an informal review.

Do not answer only by the work product. The same requirement can be reviewed informally very early, walked through with users to build understanding, technically reviewed for feasibility, and inspected when regulatory evidence is required. The objective and context drive the type, not the artefact itself. Within a single review session, multiple review techniques (ad hoc, checklist-based, scenario-based, role-based, perspective-based) can also be applied regardless of the chosen review type.

Objectives, Formality, and Review Techniques

It helps to separate three independent dimensions the exam can probe: the review type (informal/walkthrough/technical/inspection), the objective of the review, and the review technique used to read the product.

Objectives by type. Each type tends to emphasise different goals. An informal review mainly detects anomalies cheaply. A walkthrough adds education, consensus, generating ideas, and helping the author improve. A technical review targets consensus and decisions among qualified experts while still detecting anomalies. An inspection maximises anomaly detection and feeds metrics into product, document, and process improvement. A question that stresses "reach a technical decision" leans technical review; one that stresses "teach the team the new module" leans walkthrough.

Degree of formality rises with documented process, defined roles, entry/exit criteria, individual preparation, and metrics:

1. Informal review — least formal; often no preparation, no documentation.
2. Walkthrough — optional preparation; scribe common; author-led.
3. Technical review — preparation expected; moderator-led; qualified reviewers.
4. Inspection — most formal; full process, criteria, defined roles, metrics.

Review techniques are how a reviewer reads, and they cut across all types:

• Ad hoc — no guidance; reviewer reads freely. Low cost, depends on skill.
• Checklist-based — reviewers work from checklists of typical defects, improving systematic coverage.
• Scenario-based / dry run — reviewers walk realistic use scenarios through the product.
• Role-based — each reviewer evaluates from a specific stakeholder role (e.g. end user, administrator).
• Perspective-based — reviewers take different stakeholder perspectives and produce the work products they would derive (test cases, a user guide). Studies cited by ISTQB find perspective-based reading among the most effective.

For the exam: a type question keys on leadership and formality words; a technique question keys on how the reviewer reads (checklist, perspective, scenario). Do not confuse the two.