Source code inspections are a set of procedures and techniques for detecting errors (debugging) that are used by a team of specialists to examine (read) the source code. When considering source code inspections, our attention will focus mainly on methods, procedures, implementation forms, and so on.
The testing team usually includes four people, one of whom acts as chairman. The chairman should be a competent programmer, but not the developer of the program; he should not be familiar with its inner workings. The chairman is assigned to write an agenda for meetings of the testing group and schedule them, conduct meetings, record all errors found and take measures for their subsequent correction. The chairman can be compared with a technical control engineer. The members of the group are a developer of the program, a designer (if he is not a programmer) and a testing specialist. QA services are irreplaceable for verifying and validating software products being created. They help to ensure that these will be launched successfully.
The general procedure is as follows. The chairman beforehand (for example, for a few days before the process begins) distributes a listing of the program and the project specification among the other members of the team. They get acquainted with the materials before the meeting. The inspection meeting is divided into two parts:
- The programmer is asked to talk about the logic of the program. The conversation triggers questions and issues that are aimed at finding errors. Practice has shown that even demonstrating your program to the stakeholders seems to be an effective way of detecting errors while many errors are found by the programmer himself, and not by other members of the group. This phenomenon has been known for a long time and it is often used to solve problems. When the solution is not obvious, explaining the problem to another person causes the developer to “make things as clear as a bell” and the decision comes to the developer by itself.
- The program is analyzed based the list of issues to identify historically common programming errors.
The chairman is responsible for ensuring the effectiveness of the discussion. Its participants should focus on finding errors, rather than correcting them. (Error correction is performed by the programmer after the inspection session.)
At the end of the meeting, the programmer receives a list of errors found.