Why program inspections find errors

A program inspection is a formal, static review in which a small team reads the source code line by line, guided by a checklist, to find defects. The program is not executed. Fagan's early studies at IBM found that inspections removed more than 60% of the errors in a program, and later studies reported higher figures.

Why inspections are effective at discovering errors

1. Many errors are found in one session. In testing, one error can hide (mask) others: once the program crashes or gives wrong output, later faults are not reached. An inspection is a static process, so reviewers can find many unrelated defects in a single meeting.
2. Uses human knowledge of the domain and of programming. Reviewers know which mistakes are common in the language and in the application area, so they look in the right places.
3. Checklist of common faults. A checklist makes the search systematic. Typical classes are:
   • Data faults: uninitialised variables, array bounds, named constants
   • Control faults: wrong loop termination, missing break, unreachable code
   • Input/output faults: unexpected input not handled
   • Interface faults: wrong number, type or order of parameters
   • Storage faults: pointers not freed, dangling references
   • Exception faults: error conditions not handled
4. Incomplete programs can be inspected. A test needs runnable code and often a test harness, stubs and drivers. Inspection can start as soon as a module is written, so defects are found early when they are cheap to fix.
5. Checks broader quality. Reviewers also check compliance with coding standards, portability, readability and maintainability, and they spot inefficient algorithms and poor style, which testing does not report.
6. Defined roles and process. Roles (author, reader, inspector, moderator, scribe) and stages (planning, overview, individual preparation, inspection meeting, rework, follow-up) keep the review focused on finding defects, not on blaming the author.
7. Learning effect. Programmers learn from the defects found and make fewer of them later.

Planning -> Overview -> Individual preparation
                               |
         Follow-up <- Rework <- Inspection meeting

Errors unlikely to be discovered by inspections

Inspection checks the code against its specification by reading it. It cannot observe the program running, so these errors usually escape it:

• Requirements/specification errors: if the specification itself is wrong or does not meet the customer's real needs, code that matches it looks correct. This is a validation problem.
• Performance problems: slow response, poor throughput or behaviour under heavy load or stress.
• Timing and concurrency errors: race conditions, deadlocks and missed deadlines in real-time systems depend on run-time interleaving.
• Integration and emergent errors: unexpected interactions between components, or system-level properties (reliability, safety, security) that appear only when the whole system runs.
• Usability problems: whether real users find the interface easy to use.
• Environment-related faults: errors caused by the compiler, operating system, hardware, libraries or network configuration.
• Long-running resource problems: slow memory leaks or resource exhaustion that appear after hours of operation.
• Subtle numeric errors: floating-point rounding and overflow that occur only for particular data values.

So inspections and testing complement each other: inspections find many defects early and cheaply, and testing then finds the dynamic, non-functional and system-level errors.