Why do we need peer review?

Let’s discuss why we need reviews in the first place before going in to peer review. 


We all know that defect prevention is the best thing.  The next best thing is find defects early.  This significantly reduces the cost of fixing defects.  Reviews are great to -

  • Identify & remove defects – early – from software work products
  • To reduce re-work and improve productivity of software development
  • To improve quality and enhance customer satisfaction

During reviews, the software work products are examined manually or with set of tools without executing the software.  Reviews are also referred as “Static Testing”

We can review any work product – requirements/ user stories, architecture, design documents, source code, test plan, test cases, user manual and so on.

What are different review types?

Basically there are three types of Reviews

  • Self-Review – Conducted by the Author
  • Peer review- Carried out by Peers
  • External Review – Carried by teams external to project teams like SQA or even customers

Self reviews help the author to critically review their own work and reduce as many defects as possible.  Despite the best intentions, self reviews could be biased, may not catch mis-interpretations of inputs and may not catch important defects.  That is where Peer Reviews come to the rescue.

How and why peer review?

Peer review is performed by peers who are typically more experienced or of similar experience as the author, to ensure software meets specific criteria. While peers focus on finding defects and not on fixing those defects,  they may not have pre-set ideas/ bias as the authors.

Benefits of peer review

  • Communication within the team improves as there is exchange of information between the review participants
  • Participants learn about the content of software work products and plan for future stage of development
  • The type and quantity of defects found during peer review can decide whether the work product can be delivered for further reviews or to the stakeholders
  • The goal is to help the author to improve the quality of software work product under review
  • Defects like deviations from standards, missing requirements, design defects, non-maintainable code can be found during reviews.

Ways to conduct peer review:

-          Using checklist during this phase of review will be more effective and efficient. This will bring down any conflicts that may arise between the author and the reviewers.

-          Peer reviews also depend on experience, skill level and subject matter expert of the reviewer.

-          Work product need to be compared with its source/ input documents or other reference documents

-          Select the documents for the review that are most important  in the project (sampling)

-          Time spent on the peer review should be calculated based on the risk associated with the work product

Sometimes peer reviews are also done by group of people – especially when critical work products like software architecture or design is reviewed.

It is important that peer reviews are done, defects are logged based on that, root cause analysis of those defects are done – so that these defects can be prevented in the future.  We will discuss about root cause analysis and correction action (RCCA) in another blog.