When it comes to testing there are two options available for testers. To test the product, app, software by a human or by computer. These two methods have several different practices and procedures inside them. For many years it was believed as the software is going to be executed by a machine, then it should be tested by a machine too. This attitude begins to change in the early 70s when developers started to see the value of reading the software code as part of the comprehensive testing procedure.
The three main human testing methods are
- Code inspections
- Walk-throughs
- User testing (Usability Testing)
In this article we will check out code inspection together and will see
- What is code inspection
- Code inspection team
- Inspection list
- Mental considerations
- Side benefits of code inspection
- Code inspection error checklist
What is Code inspection?
Code inspection can be done in any stage of software development life cycle (SDLC) depending on the team capabilities and resources. It can be applied for new products as well as modifications for new features. Studies have shown testers using Code Inspection method have been able to detect very complicated bugs and errors which the computer-based testing was unable to detect. As a result, it is highly recommended to add this method to your testing practices too.
A code inspection is a set of procedures and error detection techniques to read code as a group of people. In code inspection, involved people, usually focus on the flow of the product or the forms that should be filled out and similar practices.
Code Inspection team
A code inspection team usually consist of 4 people. Which includes
- Moderator
- Programmer
- Designer
- Tester
Moderator
Moderator is expected to be an advanced developer and he or she is not the author of the program. Therefore, Moderator needs to get familiar with the developed software.
Moderator’s duties and tasks includes
- Distributing materials for the team
- Scheduling the Code Inspection session
- Leading and managing the session
- Ensuring detected errors are subsequently fixed.
Tester
Tester or test specialist should be professional in his/her field and be completely familiar with most common programming mistakes.
Inspection List
Few weeks before the session get started, Moderator shares the specification and features of the software with other participants, and they will learn about the application or software before session get started.
When code inspection session started two main activities occur:
- Programmer reads the code aloud statement by statement. While the programmer reading the codes and explaining it, other participants raise questions about the code. Simply reading aloud the code is a highly effective way to detect bugs and errors.
- Software is analyzed based on the previously prepared and created checklist of common programming errors.
Moderator ensures the session is productive and the participants are focusing on errors and not fixing them. Found bugs will get resolved after the session by programmer.
If there are major errors in the code, Moderator might rearrange another session of inspection after these errors resolved. Also it is suggested to create a list of errors and analyze and categorize them.
Code inspection session time should be scheduled before, to prevent all outside interruptions. An optimal amount of time for the session is 90 to 120 minutes. Longer sessions tend to be less productive.
Usually 150 code statements are getting covered within an hour. Therefore it is recommended to conduct multiple sessions for larger software each time with one or more different modules.
As mentioned before, participants should focus on bugs and not correction. For example if a minor problem found and programmer suggested a design change, again participants should focus on the bugs in the design and as a result a collection of minor and major bugs in that particular component can be found immediately.
Mental considerations
The group should take into consideration to not judge the developer(programmer) by the found bugs and errors. Everyone in the team should focus on making the software better and more stable by finding the bugs and improving the quality of the software. Also, the programmer should put aside his/her ego in the session and do not take errors personally. Managers should not take the results as a means of incompetency of the programmer. It is recommended the result of the session only shared between the participants.
Side benefits of code inspection
Apart from the main purpose of code inspection, which is finding errors, there are way more benefits with code inspection session. One of the benefits code inspection processes is programmer receives valuable feedback on the programming style, different algorithms, and techniques. Also other participants get familiar with developer’s development style and errors. In general, code inspection testing session reinforces the teamwork in involved project and other projects which the participants are part of the team.
Finally, code inspection helps to identify the most error-prone sections of the software in an early stage of the development and helping to have more attention on these sections.
Code inspection error checklist
Here’s a list of most common code errors as a checklist which can be used in the session
| Data Reference | Computation |
| Unset variable used? | Computations on nonarithmetic variables? |
| Subscripts within bounds? | Mixed-mode computations? |
| Noninteger subscripts? | Computations on variables of different lengths? |
| Dangling references? | Target size less than size of assigned value? |
| Correct attributes when aliasing? | Intermediate result overflow or underflow? |
| Record and structure attributes match? | Division by zero? |
| Computing addresses of bit strings? Passing bit-string arguments? | Base-2 inaccuracies? |
| Based storage attributes correct? | Variable’s value outside of meaningful range? |
| Structure definitions match across procedures | Operator precedence understood |
| Off-by-one errors in indexing or subscripting operations? | Integer divisions correct? |
| Inheritance requirements met? |
| Data Declaration | Comparison |
| All variables declared? | Comparisons between inconsistent variables? |
| Default attributes understood? | Mixed-mode comparisons? |
| Arrays and strings initialized properly? | Comparison relationships correct? |
| Correct lengths, types, and storage classes assigned? | Boolean expressions correct? |
| Initialization consistent with storage class? | Comparison and Boolean expressions mixed? |
| Any variables with similar names? | Comparisons of base-2 fractional values? |
| Operator precedence understood? | |
| Compiler evaluation of Boolean expressions understood? |
| Control flow | Input / Output |
| Multiway branches exceeded? | File attributes correct? |
| Will each loop terminate? | OPEN statements correct? |
| Will program terminate? | Format specification matches I/O statement? |
| Any loop bypasses because of entry conditions? | Buffer size matches record size? |
| Possible loop fall-throughs correct? | Files opened before use? |
| Off-by-one iteration errors? | Files closed after use? |
| DO/END statements match? | End-of-file conditions handled? |
| Any nonexhaustive decisions? | I/O errors handled? |
| Any textual or grammatical errors in output information? |
| Interfaces | Other Checks |
| Number of input parameters equal to number of arguments? | Any unreferenced variables in cross-reference listing? |
| Parameter and argument attributes match? | Attribute list what was expected? |
| Parameter and argument units system match? | Any warning or informational messages? |
| Number of arguments transmitted to called modules equal to number of parameters? | Input checked for validity? |
| Attributes of arguments transmitted to called modules equal to attributes of parameters? | Missing function? |
| Units system of arguments transmitted to called modules equal to units system of parameters? | |
| Number, attributes, and order of arguments to built-in functions correct? | |
| Any references to parameters not associated with current point of entry? | |
| Input-only arguments altered? | |
| Global variable definitions consistent across modules? | |
| Constants passed as arguments? |
As we explored together code inspection sessions has several benefits for the team and for the quality of the software to deliver it in a better shape. But the most important thing is to follow the instructions to make the session productive and to not judge the programmer for the detected errors to prevent pressure on the programmer, as usually people under pressure make more mistakes which results in more bugs.