Feedback and Review Process
Static analysis tools can catch syntax errors, but only human judgment can evaluate logic, business value, and requirement clarity. This topic covers the human side of static testing - how reviews are structured, who plays which role, and what separates a casual buddy check from a rigorous inspection.
~9 min read
The core ideas, explained
Benefits of Early and Frequent Stakeholder Feedback
Feedback is a form of static testing where stakeholders evaluate work products - requirements, prototypes, user stories - before major development begins. Early feedback prevents misunderstandings from being baked into the architecture, ensuring the team builds the right thing from day one. Frequent feedback keeps the team from drifting off course during development, which is a core tenet of Agile, where short iterations let stakeholders review increments constantly.
A business analyst shows a wireframe of a reporting dashboard to the sales team on day 2 of the project. The sales team immediately points out that a critical filter is missing. Fixing the wireframe takes 5 minutes; fixing it after the software was built would have taken two weeks.
The Five Activities of a Formal Review Process
Even an informal review generally touches five activities. Planning defines the scope, review type, roles, and entry/exit criteria. Initiate Review distributes the work product and any checklists, and explains the objectives. Individual Review is where reviewers work independently to read the document and note potential anomalies - this is where most defects are actually found. Issue Communication and Analysis brings reviewers together to discuss findings and determine severity and ownership. Fixing and Reporting has the author fix the agreed-upon defects, checks the result against exit criteria, and reports metrics to management.
A team planning a requirements review assigns three reviewers and a checklist (Planning), emails them the document (Initiate Review), gives them two days to read it alone and log notes (Individual Review), meets to discuss the notes and agree on severities (Issue Communication and Analysis), then the author updates the document and the team reports "12 defects found" to management (Fixing and Reporting).
Roles and Responsibilities in a Review
A productive review assigns specific roles so it doesn't devolve into an argument. The Author created the work product and fixes the defects found. Management decides how reviews are executed and allocates time and budget, but doesn't always participate directly. The Facilitator (Moderator) is the referee of the meeting - crucial for formal reviews. The Review Leader takes overall responsibility for the process and decides who's involved, sometimes combined with the Facilitator role. Reviewers are the subject matter experts, testers, or peers who independently examine the document. The Scribe (Recorder) documents all issues, decisions, and open points raised during the meeting.
In an inspection of a payment API design, the architect who wrote it is the Author, a senior engineer runs the meeting as Facilitator, two peers act as Reviewers, and a junior developer takes notes as Scribe - each role focused on one job so the meeting stays productive.
The Four Review Types
Reviews range from casual conversations to highly regimented audits. An Informal Review has no formal process or documented output, aimed at quick, cheap feedback - a "buddy check" or pair programming session. A Walkthrough is led by the Author, meant to educate the audience or gather high-level feedback. A Technical Review is led by a trained Facilitator or technical expert (not the author), using a checklist to gain consensus on technical decisions and find defects. An Inspection is the most formal type - led by a trained Facilitator, relying heavily on rules, checklists, and entry/exit criteria, with metrics collected; the Author cannot act as Facilitator.
A developer asks a colleague to glance over a SQL query (Informal Review). A developer later walks the QA team through a new feature's design so QA knows how to test it (Walkthrough). Senior architects review a junior developer's database schema for performance (Technical Review). A commercial airplane's flight control logic gets a line-by-line audit against strict criteria (Inspection).
Success Factors for Reviews
A review process fails if the culture is toxic or the logistics are poorly managed. Organizational culture must foster psychological safety, keeping the focus on finding defects in the product, not evaluating the author's performance. Reviewers need clear objectives, such as "review for security flaws" rather than "look at this code." The right people - testers, developers, business - bring diverse viewpoints. Management must allocate adequate, dedicated time for individual preparation, since skimming a document 5 minutes before the meeting makes the review useless. And continuous improvement uses gathered metrics, like defects found per page, to improve checklists and processes over time.
A team that starts blaming authors for bugs found in reviews quickly sees participation collapse - developers start hiding issues rather than exposing them - while a team that protects preparation time and reviews defects-per-page metrics keeps finding real problems release after release.
Key points to remember
- Preparation is king - the Individual Review phase is where actual defects are discovered; the meeting is just for discussing them.
- Walkthroughs are Author-led - the author explains the document to an audience.
- Inspections are Facilitator-led - highly formal, metric-driven, with strict rules.
- Blame-free culture matters - if authors fear for their job over bugs found in review, they'll hide defects or refuse to participate.
- The Scribe writes things down during the meeting, freeing everyone else to focus on the discussion.
Terminology
A few terms from this topic worth knowing precisely.
Examining a work product - requirements, design, code, or testware - without executing it, typically through review or static analysis.
Any artifact produced during the SDLC that can be examined - a requirement, a design document, source code, or a piece of testware.
A static testing technique where people - not tools - examine a work product to find defects and evaluate its quality, ranging from a casual chat to a highly formal inspection.
The phase of a formal review where each reviewer works alone to read the document, spot potential anomalies, and take notes - where the majority of defects are actually found.
A lightweight review with no formal process and no documented output required, aimed at quick, cheap feedback - a "buddy check" is the classic example.
A review led by the Author, meant to educate the audience, build a shared understanding of the work product, or gather high-level feedback.
A review led by a trained facilitator or technical expert (not the author), using a checklist to gain consensus on technical decisions, weigh alternatives, and find defects.
The most formal review type - led by a trained Facilitator, driven by rules, checklists, and entry/exit criteria, with metrics collected. The Author cannot act as Facilitator.
The referee of a review meeting - keeps it running smoothly, manages time, and mediates disputes between participants. Crucial for formal reviews.
The person who takes overall responsibility for a review and decides who will be involved - sometimes combined with the Facilitator role.
The person who documents every issue, decision, and open point raised during a review meeting, freeing everyone else to focus on the discussion.
A review culture where the focus stays on finding defects in the product, not on judging the author's performance - without it, people hide defects or avoid participating.
Summary
Reviews are the primary human-driven method of static testing. By defining clear roles and following a structured process, teams can systematically remove defects from documents and code before dynamic testing begins. Choosing the right review type - from an informal buddy check to a strict inspection - depends on the project's risk level. The ultimate success of any review relies on management giving the team enough time to prepare and fostering a culture of psychological safety.
| Concept | One-line memory hook |
|---|---|
| Early & frequent feedback | Catching misunderstandings before they turn into code |
| Individual Review activity | The phase where reviewers actually find the bugs |
| Facilitator (Moderator) | The referee who keeps the review meeting on track |
| Informal Review | A quick "buddy check" at a colleague's desk |
| Walkthrough | The Author leads the group to educate them on the product |
| Technical Review | Peers or experts review technical decisions to reach a consensus |
| Inspection | Highly formal, metric-driven, strict entry/exit criteria |
| Psychological safety | Critique the product, not the person who wrote it |
Check your understanding
10 quick questions - click an option to see if you got it right.