Like testing, walkthrough (known also as a peer review) includes a set of procedures and methods for detecting errors that are performed by a group of people examining a software program code. Such a scan has much in common with the test process, but its procedures as well as error detection methods are somewhat different.
Like testing, a walkthrough is conducted in the same way as an ongoing meeting, lasting for one or two hours. The walkthrough team includes 3-5 people. It has a chairman whose responsibilities and duties are similar to those of a test team lead. Besides, a secretary who records all the errors found, and a testing specialist are among the members. There are diverse opinions about who should be the fourth and fifth members of the group. Without doubt, one of them must be a programmer. Regarding the fifth participant, the following assumptions are available:
1) highly qualified programmer;
2) expert in a programming language;
3) beginner (whose viewpoint is not affected by previous experience);
4) person who will ultimately use the program;
5) participant of any other project;
6) someone from the same group of programmers as the author of the program.
The demand grows for quality assurance and testing services helping the developers to always meet needs and expectations of the wider public.
A walkthrough starts with the same procedure as the test process: participants receive work materials in advance, a few days before the meeting, allowing them to familiarize themselves with the program. However, this procedure is different from the procedure that takes place during the test process. Instead of just reading the code of the program or using a list of errors, the participants in the meeting “perform functions of a computer”. A person assigned as a tester offers a small number of tests written on paper, representing sets of input data (and expected output data) for a program or module. During the meeting, each test is performed in the heads of the participants. This means that the test data are processed in accordance with the program logic. The state of the program (i.e., values of the variables) is tracked and the results are recorded on paper or a board.
Of course, there should be a small number of tests and they should be simple, because the speed with which a man executes the program is too many times slower than that of the machine. Consequently, the tests themselves do not play a critical role, they rather help to initially understand the program and serve as the basis for questions to ask the programmer about the design logic and approved assumptions. In most walkthroughs, when performing the tests themselves, fewer errors are found than when surveying the programmer.
Add Comment