Types of Reviews

Profile picture for user devraj

Review can be used for various purposes, but its main objective is discovering defects. You can use different review types in defect detection. The type of defect found during the review also depends on the work product being reviewed. Reviews can be categorized according to different attributes. These attributes are characterized by the level of documentation, entry and exit criteria, process, and rules pertaining to the review. The Four Most common types of Reviews are:

  1. Informal Review
  2. Walkthrough
  3. Technical Review
  4. Inspection

The above types of reviews can be done as peer reviews. When a review is done by a qualified colleague who is suitable to perform the review, it is known as a peer review. A single work product can be reviewed using one or more review types. When more than one type of review is used, the order may vary. For example, an Informal review is carried out before the technical review to ensure that the work product is ready for technical review.

The decision about what type of review is appropriate must be made on a case-by-case basis. Selecting a review type should be  based on the following factors:

  • Business Domain
  • Company Culture
  • Resource Availability 
  • Product Risk
  • Product Type
  • Project Need

Let's go through each review type.

1. Informal Review

The informal review is also known as buddy check, pairing, and pair review. Attributes of Informal Review are: 

  • Main Purpose: The primary purpose of the informal review is to detect potential defects.
  • Possible Additional Purposes: Additional possible purposes are generating new ideas or solutions and quickly solving minor problems.
  • Forms: It can take several forms like pair programming, buddy testing, and code swapping are some informal reviews.
  • Review Meeting: There is no requirement for a  formal review meeting and a facilitator of an informal review. The author initiates an informal review. 
  • Reviewer: Informal review is performed by colleagues or by more people. It varies in usefulness depending on the reviewers. Generally, the developer review other developers' code, or the tester review other testers' test cases.
  • Scribe or Recorder: A scribe or Recorder is not required in informal review. 
  • Checklist: The use of a checklist is optional.
  • Individual Preparation: Individual preparation is not required before review.
  • Output: Results of informal review may be documented. 
  • When to Use: It is commonly used in Agile Development. Due to the minimal effort required, the informal review is highly accepted. It also saves cost and effort.

2. Walkthrough

Walkthroughs are typically used to check early drafts of work products. Attributes of Walkthrough are: 

  • Main Purpose: The primary purposes include defect finding, improving software products, considering alternative implementation, evaluate conformance to standards and specifications. 
  • Possible Additional Purposes: The possible additional purposes of the walkthrough are exchanging ideas about techniques or style variations, participants training, achieving consensus
  • Forms: Walkthroughs may take the form of scenarios, dry runs, or simulations. This may vary in practice from quite informal to very formal.
  • Review Meeting: The author leads the walkthrough review meeting and explains the content of the document step by step. 
  • Reviewer: There is no limit to no of people involved in the walkthrough meeting. A large audience can participate. 
  • Checklist: The use of a Checklist is optional.
  • Individual Preparation:  Individual preparation is not required in the walkthrough.
  • Scribe or Recorder: A scribe or Recorder is Mandatory.
  • Output: Potential defect logs and review reports are produced as an outcome of the walkthrough.
  • When to Use: A walkthrough is useful for higher-level documents like requirement specifications and architectural documents. This review is helpful when people from outside the software discipline are present with little or no knowledge of software development and its documents.

3. Technical Review

A well-defined process focuses on finding defects and evaluating the quality of technical work products. Technical reviews vary from quite informal to very formal. Attributes of Technical Review are: 

  • Main purposes: Purposes are gaining consensus, detecting potential defects
  • Possible further purposes: Additional purposes of technical reviews are: evaluating work product quality and building confidence in it, generating new ideas, motivating and enabling the author to improve future work products, considering alternative implementations  
  • Review Meeting: The review meeting is optional, ideally led by a trained facilitator, and typically not led by the author in case of technical review. 
  • Reviewers: Reviewers should be technical peers of the author and technical experts in the same or other disciplines. The experts include architects, chief designers, and key users. Management does not participate in review meetings.
  • Checklist: The use of a checklist is optional. 
  • Individual Preparation: Individual preparation before the technical review meeting is required. 
  • Scribe or Recorder: The involvement of the scribe is mandatory. Ideally, the scribe must be someone other than the author. 
  • Output: The outcome of technical reviews is potential defect logs and review reports are produced. The review result must be approved with the agreement of everyone involved and signed by everyone. Disagreement should be noted in the protocol.
  • When to use: Technical reviews evaluate the quality of technical work products. 

4. Inspection

Inspection is a formal review process based on rules and checklists and specified entry and exit criteria for acceptance of the work product. Other attributes of Inspections are: 

  • Main purposes: The inspection's primary goals are detecting potential defects, evaluating quality and building confidence in the work product, preventing future similar defects through author learning and root cause analysis
  • Possible further purposes: Further purposes of inspection include: motivating and enabling authors to improve future work products and the software development process, achieving consensus
  • Review Meeting: The inspection review meeting is led by a trained facilitator, not the author. The author cannot act as the review leader, reader, or scribe. 
  • Reviewers: Reviewers are either peer of the author or experts in other disciplines that are relevant to the work product. Inspection Uses clearly defined roles which are mandatory and may include a dedicated reader (who reads the work product aloud and often paraphrase, i.e., describes it in his own words, during the review meeting. 
  • Checklist: Follows a defined process with formally documented outputs based on rules and checklists
  • Individual preparation: Individual preparation before the inspection review meeting is required.
  • Scribe or Recorder: scribe is mandatory for inspection.
  • Output: Potential defect logs and review reports are produced. Metrics are collected and used to improve the entire software development process, including the inspection process.
  • When to use: Inspection is helpful for work products related to safety-critical applications.