Software walkthrough
 | This article relies largely or entirely on a single source. (October 2011) |
In software engineering, a walkthrough or walk-through is 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".[1]
"Software product" normally refers to some kind of technical document. As indicated by the IEEE definition, this might be a software design document or program source code, but use cases, business process definitions, test case specifications, and a variety of other technical documentation may also be walked through.
A walkthrough differs from software technical reviews in its openness of structure and its objective of familiarization. It differs from software inspection in its ability to suggest direct alterations to the product reviewed, its lack of a direct focus on training and process improvement, and its omission of process and product measurement.
Process
A walkthrough may be quite informal, or may follow the process detailed in IEEE 1028 and outlined in the article on software reviews.
Objectives and participants
In general, a walkthrough has one or two broad objectives: to gain feedback about the technical quality or content of the document; and/or to familiarize the audience with the content.
A walkthrough is normally organized and directed by the author of the technical document. Any combination of interested or technically qualified personnel (from within or outside the project) may be included as seems appropriate.
IEEE 1028[1] recommends three specialist roles in a walkthrough:
- The Author, who presents the software product in step-by-step manner at the walk-through meeting, and is probably responsible for completing most action items;
- The Walkthrough Leader, who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author); and
- The Recorder, who notes all anomalies (potential defects), decisions, and action items identified during the walkthrough meetings.