Software inspection, review, and walkthrough

A student asked me: “Can you tell me the differences between software walkthrough, review, and inspection. Which method is better and why there are so many of them?

Answer: There are several methods to identify defects during the software development. (Review, walkthrough and Inspection) The most effective is software formal inspection or Fagan inspection as it was developed by Michael Fagan of IBM in the 70s. According to this method, inspection must be formal; materials to be inspected must be prepared and meet the inspection entry criteria; and people who inspect must be qualified, as well as the time and place must be arranged ahead of time. There are formal roles for each participant and they must be trained in the method. (Moderator, Recorder, Inspectors, Author as minimum) The participants must review the materials ahead of the meeting (At least few days). The main purpose of the inspection meeting is only to find defects NOT solution. After the inspection, the author of the work (i.e., developer) must rework all defects. There is a follow up session where the inspection moderator, quality assurance or sometime the entire inspection team will review to verify that all defects have been fixed and no additional defects have been introduced.

Reviews and Walkthroughs are not as formal as Inspection but they are useful and can be used in addition to formal inspections. Basically a walkthrough is a group review of any technical product by people who work on the same project. (It could be programmers, designers, developers, or anyone who may be involved in various phases of the project) to look into someone ‘s work and made comments regarding defects. As a non-formal, a walkthrough should not include the project managers, the director, or users. The reason for walkthrough is to identify errors as quickly as possible. A walkthrough can take place at anytime and anywhere in the development of a software product.

A review is more formal than a walkthrough but not as formal as an inspection. Reviews that are usually conducted at the end of each phase in the software development lifecycle such as requirements review, architecture review, or design review. The purpose of reviews is to make sure that everything that need to be done in a lifecycle phase are done so developers can go on to the next phase. As a general checking point, it may not catch errors as an inspection. Review does involve the project manager, the director or customers and users.

I have written in detail about these methods in this blog, please read them.

Sources

  • Blogs of Prof. John Vu, Carnegie Mellon University