06 Software Review and Inspection

Software quality assurance

is a structured approach to improve software quality. It involves defect prevention, detection, and removal, as well as defect containment activities

Software inspection or software review

is a formalized peer review process for detecting and correcting defects or bugs in software artifacts.

Some of the most well-known software inspection methodologies are the following:

Fagan inspection methodology and Structured Walkthrough

Fagan inspection methodology

. The objectives of this methodology are to identify and remove errors in the software products and to identify any systematic defects in the processes that are used to create software products.

Michael Fagan

This Fagan inspection methodology was developed by him

These are the following inspector roles that each participant plays as defined in the Fagan inspection process:

Moderator

Author

Reader

Tester

Moderator

S/He leads the inspection team and takes care of logistics.

Author

– S/He is the creator of the software artifacts under inspection. The author will actively answer all the questions regarding the artifacts during the inspection meeting. The author is responsible for fixing identified defects and bugs in the artifacts.

Reader

– S/He is an experienced peer who can be a subject matter expert on the software artifacts under inspection.

Tester

– S/He is responsible for writing and executing test cases for the software module or product. The role of the tester is focused on how the product would be tested.

the seven (7) activities of the Fagan inspection methodology:

Planning

Overview

Preparation

Inspection Meeting

Process Improvement

Rework

Follow-up

Planning - Moderator

• Identify inspectors and roles.

• Verify if the materials are ready for inspection.

• Distribute inspection materials to participants.

• Arrange meeting place and time

Overview - Author

• Brief participants on information of materials.

Preparation - Inspectors

• Participants prepare for the meeting.

• Checklists may be employed to facilitate the preparation.

• Read through the deliverables and mark up issues and questions

Inspection Meeting - Moderator/Inspectors

• The moderator sets the time limit for inspection and keeps the meeting focused.

• The inspectors perform their roles to find defects. The emphasis is to identify as many possible defects, not solutions.

• Record and classify defects.

• An inspection outcome is agreed.

Process Improvement - Inspectors

• Continuously improve the development and inspection process.

• Record the causes of major identified defects.

• Perform root cause analysis to identify any systemic defect with development or inspection process.

• Determine corrective action to address any systemic defects in the software process.

• Make recommendations to the process improvement team.

Rework - Author

• The author corrects the defects and carries out any necessary investigations.

Follow Up - Moderator/Author

• The moderator verifies that the author has resolved the defects and investigations.

Inspection Type: 

Requirements

Design Inspection

Code Inspection

Test Plan Inspection

Requirements PURPOSE

• Find requirements defects.

• Confirm if the requirements are correct.

Design Inspection PURPOSE

• Find defects in design.

• Confirm if the design is correct with respect to requirements.

Code Inspection

• Find defects in the source code.

• Confirm if codes are correct with respect to design and/or requirements.

Test Plan Inspection

• Find defects in test cases or test plan.

• Confirm if test cases can verify the design and requirements.

Requirements PROCEDURE

• Inspectors review each page of requirements and raise questions or concerns.

• The moderator records identified defects

Design Inspection PROCEDURE

• Inspectors review each page of design, compare it to requirements, and raise questions or concerns.

Code Inspection PROCEDURE

• Inspectors review the code, compare it to requirements and/or design, and raise questions or concerns.

• The moderator records identified defects

Test Plan Inspection PROCEDURE

• Inspectors review each page of test plan or specification, compare it to requirements and/or design, and raise questions or concerns. \

• The moderator records identified defects.

Structured Walkthrough

– It is a peer review in which the author of a deliverable, such as a document or source code, brings one (1) or more reviewers through the deliverable

These are the following steps of a structured walkthrough:

Step 1: The author circulates the deliverable, either physically or electronically, to the review audience.

Step 2: The author schedules a meeting with the reviewers. Step 3: The reviewers familiarize themselves with the deliverable.

Step 4: The review leader chairs the meeting.

Step 5: The author brings the review audience through the deliverable, explains what each section aims to achieve, and requests comments from them as to its correctness

Step 6: The scribe records errors, decisions, and any action items.

Step 7: A meeting outcome is agreed, and the author addresses all agreed items. If the meeting outcome results in a second review, then go back to Step 1.

Step 8: The deliverable is circulated to reviewers for sign off, and the reviewers sign off indicating that the author has correctly amended the deliverable.

Step 9: The author or project leader stores the comments and sign-offs.

Code reviewing or inspection

is the act of systematically convening with fellow programmers to check each other’s code for faultsto ensure the code meets quality standards. may focus on coding standards only or as well asfinding defects in the software code. The identified issues during the review are recorded and may include items requiring further investigation.

There are two (2) families of approach to identify defects in source codes:

Tool-Driven Code Review and Developer-Driven Code Review

Tool-Driven Code Review 

– This approach uses automated code analysis techniquesthat can pick out problematic patterns within the source code. The source code analysis drive automated code reviews. The code checkers are often built-in into Integrated Development Environments (IDEs).

Developer-Driven Code Review

– Some properties of code quality are difficult to assess automatically. In this approach, the developers themselves reviews the code to pick out problems. Then, the reviewers manually assess source codes before deployment.

Modern code review

is a lightweight variant of the code inspections because it does not rely on face-to-face meetings. This operates on tools and development processes.

These are the two (2) version repository-based tools used to compose lightweight code reviews:

Tool-Driven Code Review and Pull-Based Development

Tool-Driven Code Review (repository-based tools)

– To enable code reviews, integrate reviewing tools such as Google’s Gerrit and Microsoft’s CodeFlow with version repositories to act as gatekeepers to commits. A repository is a central file storage location. It is used by version control systems to store multiple versions of files that can be accessed by multiple users.

Pull-Based Development

– This development approach enforces modern code review and does not use code reviewing tools. This revolves around a mechanism known as a “pull request.”