code_walkthrough
A walkthrough is a set of procedures and error-detection techniques
for group code reading. It is also an exercise of role playing that
allows an independent tester to walk through the code with a team.
How do we do that?
<![CDATA[
o Assign a moderator to do the following:
- distribute the program source and design specification
- schedule the session
- lead the session
- ensure errors are corrected
- update "frequently encountered" errors checklist
]]>
This person must be a competent programmer but not the programmer.
<![CDATA[
o Assemble the group with the following functions.
- tester
- maintenance programmer or outside programmer
- the programmer
- librarian for recording errors
]]>
The moderator distributes the program and design specifications several
days before the walkthrough. The group should come after having read
and become familiar with the specification and/or code.
The tester prepares a paper set of inputs to represent typical program
activity. This should be limited in scope and not an exhaustive list
of program activity.
The tester comes prepared with a small set of paper inputs that the
team will walk through as they simulate the computer. The state
of the machine will be monitored on paper or on the board. The
programmer should be questioned about the logic or assumptions
as appropriate. Side affects should be noted and observed.
Experience has shown that many of the errors in a program will be
found by the questions to the programmer during such activity. It
is important to comment about the program and not the programmer.
Errors are inherent in the difficulty of program development. The
tester's input should be considered a vehicle to encourage questions
and probing about the program.
The moderator compiles a list of errors for the programmer. The list
should be analyzed, categorized, and used to refine the
error checklist
which improves Code Inspection Activity.
The moderator should assign another walkthrough if the error list
warrants another detailed look. The moderator ensures that the error
list is corrected by the programmer.
Management issues and management reporting do not belong in walk
through sessions. The programmer should not feel uneasy about
looking openly at the code. If statistics are gathered from session
to session, they should be gathered as a collective group over a
period of time.
Organizations report:
<![CDATA[
150 line of code per hour is typical
Optimal time to be 1 to 2 hours.
Exposure to other programming styles benefits the group
Identifies early the most error-prone sections of code
]]>