Software Code Inspection Process:
When software is complete, usually in chunks of 200 to 250 lines of code, the developer schedules a review by his or her peers. The peers, usually a small group of four or five, are invited to a meeting. The meeting should last no more than two hours because people get tired after that. The developer provides copies of the source code to be inspected and the checklists to be used to review the source code. The goal is to have the reviewers look at the software prior to the meeting. During the meeting, checklists are usually looked at to remind the people what kinds of errors they are looking for. The developer also brings to the meeting any related material, such as a design or requirements document. One or more checklists are filled out summarizing the defects found, comments made, and action items to be taken after the meeting. The listing of the source code is usually marked up with corrections made by the reviewers. After the meeting, the defects are corrected and checked by someone else to make sure the corrections have been properly made. The source code is then usually placed under some type of control.


Software Testcase Review/Inspection Process:
When the testcase is complete, the tester schedules a review with his or her peers. The peers, usually a small group of around two are invited to a meeting. This can also be scheduled as an offline review or inspection. Where the defects and feedback are captured in a tool for fixing by the tester at a later stage. During the review, checklists are usually looked at to remind the people what kinds of errors they are looking for. The tester may also include any related material, such as a design or requirements document for reference.


Checklists and types of defects for code review inspection :
Checklists are used to remind and record the types of errors that are supposed to be looked for during inspections. Depending on the source code language, these errors usually include the following:

• Coding or Logic Error
• Data Error
• Input/Output Error
• Constants used instead of numeric values
• Timing Problem
• Programming standard not followed
• Conflict with the requirements
• Not enough comments
• Variable not initialized
• Code doesn't match the design
• Code not clearly written or hard to follow
• Loop error (off by one, out of range)
• Dead code (code is not used or reached)
• Pointer or address errors
• Memory overlap

The Focus on Code Inspection:
Because any error can lead to the downfall of a system, it's hard to claim that one type of review is more important than another. [Freedman/Weinberg]. Code reviews have received so much attention because most people think that most errors are in coding and that those errors are the most important ones. This is also because coding is the step in which we usually find a lot of errors. Code reviews are therefore the best place to start to implement reviews because: "...we might as well take advantage of the feelings that people have concerning coding errors. Like the doctor who is going to have to perform a painful procedure on a patient, we may need the patient's pain as motivation to get the procedure accepted.... The results from code reviews are most likely to be readily translated into facts that many people will be able to appreciate. [Freedman/Weinberg].


Once software engineers realize the benefits of inspections, they are more willing to practice other types of reviews or inspections such as requirements reviews, or design reviews. The more times a programmer/tester attends reviews/inspections, the better he or she becomes in not repeating those same types of errors. And the better he or she becomes in being able to spot those same errors made by others.