To improve quality and to reduce defects, developers often ask other team members to review their work to determine whether they have defects or not. The reason is to avoid “personal bias” because if developers are doing their own review, they may follow the same logic that they used to do the work and will not be able to detect any error that they made. Another person could do better in finding defects because he has different perspective. In “Peer Review”, team members examine each other’s work and provide feedback to the authors. Peer Review can be informal or formal, depending on the purpose of the review.

Informal review

In an “Informal review” the author asks one team member to examine his work. He does not know how the other team member conducts the review and how comprehensively the review is done. The “Informal review” is depending on the knowledge and skill of the reviewer so the result varies greatly. Some do a good job but other may not. When finish, the reviewer can tell the author the number of defects or bugs that he must fix.

In “Pair programming” (Mostly use in Extreme Programming) two developers work on the same product simultaneously at the same place. One do the work, the other observes and provide comments, after a while they switch side. The idea is two persons is better than one and it helps better discussion between team members, and provide opportunity for continuous review of each person’s ideas. In Pair programming, every line of code is written by two people working together which leads to higher quality products. Pair programming can be used to create any software product, not just code. From the “Extreme programming” view, pair programming promotes collaboration, teamwork, and a shared commitment to the quality of the product.

Formal review

In “Software Inspection” or “Formal review” the project team follows a well-defined process with specific roles assigned to individual participants. The inspection process has several phases:

• Planning
• Preparation
• Review
• Rework
• Follow-up.

In this type of review, team members should be trained in the inspection process and be able to perform different roles. Software Inspection always follows a checklists of common defects found in different types of software products, rules for conduct review, and various analytical techniques to search for defects. The review team often consists of a Moderator who manage the review; the Author whose work is being reviewed; at least two Reviewers who conduct the review; and a Recorder who document the issues as they are brought up. Reviewers receive the work at least few days or a week before the review date so they can prepare for the review. Reviewers examine the work in advance to understand it and to find problems. During the meeting, the Moderator goes over the material with reviewers, who raise issues and point out possible defects. The Moderator helps the review team reach the same interpretation of each work. The author listens carefully to the issues raised but do not argue with the comments. The recorder document all issues raised during the meeting. At the end of the review, the reviewers leave the meeting. The Moderator and the Author go over the issue lists and discuss the review and agree to fix the problems identified. During rework, the author fixes the problems (Defects, bugs etc.) Software Quality Assurance reviews the rework and compare with the list to make sure that all problems have been fixed before allow it to be released.

Formal review (Software Inspections) is more effective at finding defects than informal review but it requires more time and trainings to do it correctly. The project manager must plan all reviews, both informal and formal during the planning of the project.