Software Review Types

Why reviews are classified by formality

Every review type pursues the same broad goals — find defects, evaluate quality, build shared understanding — but gives them different weight. At the informal end, speed and low cost matter most; at the formal end, thoroughness, repeatability and data for improving the process. The more formal the review, the more of the generic process it follows, the more clearly roles are separated, and the more it documents and measures.

Two other references use slightly different vocabularies. IEEE 1028-2008, the IEEE standard for software reviews and audits (listed by IEEE as inactive-reserved), defines five types: management reviews, technical reviews, inspections, walkthroughs and audits. Its management review monitors progress and evaluates plans and schedules; its audit is an independent examination of conformance to standards, regulations, plans or procedures. Neither is primarily about finding defects in the technical content of a work product. ISO/IEC 20246 describes a generic framework for work product reviews — process, roles and techniques — which the ISTQB review process follows closely.

Informal review

An informal review follows no defined process and does not require a formal documented output. Its main objective is detecting anomalies. A colleague reading a pull request, a tester looking over a user story before refinement, a “can you check this query?” message: all informal reviews. Pair programming and pair testing act as continuous informal reviews.

Informal reviews are cheap and fast, which is why they are the most common. Their weakness is the absence of any check on depth: without preparation or a checklist, an informal review can become a rubber stamp. Two habits help: tell the reviewer what to focus on, and let automated checks handle formatting so the reviewer’s attention goes to logic.

Walkthrough

A walkthrough is led by the author, who takes participants through the work product — often by stepping through a scenario or a dry run. CTFL v4.0 lists a broad set of objectives: evaluating quality and building confidence, educating reviewers, gaining consensus, generating new ideas, motivating and enabling authors to improve, and detecting anomalies. Individual preparation before the session is possible but not required.

Walkthroughs suit work products that others must understand to use: a test plan presented to the team that will execute it, a new architecture explained to developers who will build on it, a complex business rule explained to testers. The risk is that the author controls the narrative and steers past weak spots, so invite at least one participant whose job is to ask “what happens if…?”.

Technical review

A technical review is performed by technically qualified reviewers and led by a moderator. Its main objectives are to gain consensus and make decisions about a technical problem; it also detects anomalies, evaluates quality, builds confidence, generates new ideas and helps authors improve. Reviewers are expected to prepare individually, and the outcome — findings and decisions — is recorded.

Typical subjects are design choices and specifications: choosing between two data models, approving an API contract before implementation, deciding how a service will handle a dependency outage. The value of the moderator is that the discussion ends in a decision, not in the loudest opinion.

Inspection

An inspection is the most formal review type. It follows the complete generic review process, and its main objective is to find the maximum number of anomalies; it also evaluates quality, builds confidence and motivates authors to improve. Metrics are collected and used to improve the software development lifecycle, including the inspection process itself. In an inspection the author cannot act as the review leader or the scribe.

Inspections descend from the work of Michael Fagan at IBM in the 1970s. In practice they use entry criteria (the document is complete enough to inspect), checklists derived from past defects, individual preparation by every reviewer, a moderated meeting that logs findings rather than debating fixes, formal rework and a check that the rework is done. They are expensive, so reserve them for work products where a missed defect is costly: payment or tax calculation rules, security-critical code, regulatory requirements, safety-related logic, data migration scripts.

The four types compared

The table summarises the characteristics described in CTFL v4.0, with typical practice filled in where the syllabus leaves a choice. Treat it as a guide: a team may run a technical review with inspection-style checklists, or an informal review with a short written log.

Inspection metrics usually include the size of the work product, preparation time per reviewer, meeting time, findings by type and severity, finding density (per page or per thousand lines), rework effort and, later, the defects that escaped the review. The purpose of these numbers is to improve the process — never to judge the author or the reviewers.

                Informal review   Walkthrough          Technical review       Inspection
Main purpose    find anomalies    understanding,       consensus and          find as many
                quickly           education, ideas     technical decisions    anomalies as possible
Formality       lowest            low to medium        medium to high         highest
Led by          nobody / author   the author           a moderator            a review leader;
                                                                              never the author
Roles           author +          author +             moderator, qualified   all roles, clearly
                1..n reviewers    participants         reviewers, scribe      separated
Preparation     optional          optional             expected               required, with checklists
Documentation   none required     optional notes       findings + decisions   entry/exit criteria, log,
                                                                              report, rework check
Metrics         rarely            rarely               optional               collected and used to
                                                                              improve the process

The generic review process

CTFL v4.0 describes five activities of the generic review process defined in ISO/IEC 20246. The more formal the review, the more of the tasks in each activity are needed: an inspection follows the complete process, while an informal review follows no defined process.

• Planning — define the scope: the purpose of the review, the work product, the quality characteristics to evaluate, the areas to focus on, the exit criteria, supporting information such as standards, and the effort and timeframe.
• Review initiation — make sure everyone and everything is ready: participants have access to the work product, understand their roles and responsibilities, and have what they need, such as checklists and related documents.
• Individual review — each reviewer examines the work product on their own, applying one or more review techniques such as checklist-based or scenario-based reviewing, and logs anomalies, recommendations and questions.
• Communication and analysis — the anomalies are discussed and analysed, usually in a review meeting or in the review tool. For each one, the group decides its status, ownership and the action required, and decides the quality level of the work product and any follow-up, which may include another review.
• Fixing and reporting — defect reports are created for findings that need corrective action so they can be tracked; when the exit criteria are met the work product can be accepted, and the review results are reported.

Try it: AI Requirement Ambiguity Detector Try it: AI Acceptance Criteria Reviewer Try it: Text Diff

Review roles

CTFL v4.0 names six principal roles. In an informal review one or two people cover all of them; in an inspection they are assigned to different people. ISO/IEC 20246 describes further, more detailed roles.

• Manager — decides what is to be reviewed and provides resources such as staff and time.
• Author — creates the work product and fixes it after the review.
• Moderator (facilitator) — ensures the review meetings run effectively: mediation, time management and a safe environment in which everyone can speak freely.
• Scribe (recorder) — collates anomalies from the reviewers and records review information such as decisions and new anomalies found in the meeting.
• Reviewer — performs the review. A reviewer may be a team member, a subject-matter expert or any other stakeholder; choosing reviewers with different perspectives (user, tester, operations, security) finds different defects.
• Review leader — takes overall responsibility for the review: decides who is involved and organises when and where it takes place.

What makes reviews succeed

• Clear objectives and measurable exit criteria. Evaluating the participants must never be an objective.
• The right review type for the work product and its risk — an inspection for payment rules, an informal review for a copy change.
• Small chunks. Reviewers lose concentration on long documents and large diffs; split the work so each session stays focused.
• Feedback to authors and stakeholders, so the product and the process both improve.
• Enough time to prepare, planned into the schedule rather than squeezed between other tasks.
• Visible support from management, and reviews treated as part of the organisation’s culture of learning and improvement.
• Training for participants in their roles and in the review techniques.
• Facilitated meetings that log findings and decisions instead of redesigning the product in the room.
• Comments about the work, not the person — for example, “this branch never handles an expired token” rather than “you forgot expired tokens”. Google’s code review guide makes the same point for code reviews.

Practical examples and a review log

For example, one team might choose review types like this: a two-line bug-fix pull request gets an informal review by one peer, with CI static checks as the gate; the regression test plan for a new release is presented in a walkthrough led by the test lead to the testers who will run it; the choice between two caching strategies for the product catalogue API goes to a technical review with an architect, two senior developers and an operations engineer, moderated, with the decision recorded; and the refund rules for a payment feature go through an inspection with a checklist built from past refund defects.

A review log does not need a special tool. The fictional example below shows the fields that make findings traceable and metrics possible.

Review:     REQ-PAY-014 Refund rules v0.3            Type: Inspection
Leader:     Noura A.   Moderator: Omar K.   Scribe: Priya S.   Author: Fahad M.
Entry:      document complete, linked to epic PAY-7, checklist CL-REFUND v2 attached
Exit:       no open major findings; every minor finding has an owner

ID    Where   Type          Sev    Finding                                          Owner  Status
F-01  2.1     Ambiguity     Major  "Refunds are processed promptly" has no time     Fahad  Open
                                   limit. State it in business days.
F-02  3.4     Omission      Major  No rule for a partial refund on an order         Fahad  Open
                                   paid with a discount code.
F-03  4.2     Consistency   Minor  Refund limit is 5,000 SAR here, 3,000 SAR        Fahad  Fixed
                                   in 6.2.
F-04  AC-7    Testability   Minor  "The customer is informed": by which channel,    Fahad  Open
                                   and within what time?

Metrics:   9 pages · preparation 4 h 10 min total · meeting 45 min · 4 findings (2 major)
Decision:  rework required; moderator verifies the fixes before acceptance

Try it: AI Test Case Optimizer Try it: AI Duplicate Test Case Detector Try it: AI Test Coverage Analyzer

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISO/IEC 20246:2017 — Software and systems engineering — Work product reviewsISO/IEC · 2017A generic framework for reviewing work products — the review process, roles and review techniques.
• IEEE 1028-2008 — IEEE Standard for Software Reviews and AuditsIEEE Standards Association · 2008The classic definitions of management reviews, technical reviews, inspections, walkthroughs and audits (listed by IEEE as inactive-reserved).
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• Code Review Developer GuideGoogle (eng-practices)Google's published code review practices: what reviewers look for, the standard for approving a change and how to write review comments.