Software inspections are a disciplined engineering practice for detecting and correcting defects in software artifacts, and preventing their leakage into field operations. Software walkthroughs are, on the other hand, a form of software peer review in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems.
What is the difference between the two? An inspection is a more formal process than a walkthrough, which is used to collect metrics or statistics about the software process. Walkthrough is a more informal version of an inspection.
Inspections and walkthroughs are primarily targeting to discover defects in software artifacts, and they belong to a static analysis technique of the software testing. Inspections, in addition, are used in three major tasks of software testing management: planning, measurement and control. Inspections are part of IEEE standard since 1988.
Inspections are used to collect quantitative quality data at defined points in the development process. This can be used to give feedback to the developers, feed-forward to future development, and feed-into future steps of process. Inspections can also provide data on effectiveness of inspection techniques.
Inspections can be held at various points during the development process, and usually inspected artefacts are detailed design, code, requirements, etc. A formal inspection process must include at minimum designated moderator, author of the artefact under inspection and at least one peer inspector. In case of walkthrough, designated moderator is not required, and author of the software often lead the process.
After planning and individual preparation by inspectors (studying the material of the inspection), meeting is conducted by moderator. During the meeting, agenda includes examining material, recording defects and reviewing defects. Common problems during the meetings are mostly connected to the interpersonal tensions which are likely to arise at this point. However, the more inspections that occur, the less likely these tensions will interfere. Additional effort should be made by all participants to keep emphasis on producing quality product, not making fault finding personal.
After the meeting, rework is performed by the author in response to defect list determined during the meeting. After rework, follow-up meeting is scheduled, where moderator verifies that corrections were implemented.
Initial introduction of inspection into an organization can cause anxiety and tension among developers. When it becomes clear that management supports inspection as a quality improvement technique and not a witch hunt, the effectiveness of the inspection increases.
Quality assurance is responsible for recommending inspection and preparation rates – actual review data makes these more realistic. Defect rates and types discovered at different points can point to the most effective place to review. For example, design inspections may prove more cost effective than code. Inspections have been proven an efficient and effective method for improving software quality. In conjunction with testing, audits and formal verification, a successful, quality product can be produced.
The post Software Inspections and Walkthroughs appeared first on Merit Solutions.