---
title: "Why program inspections find errors"
subject: "Software Engineering"
chapter: 7
key: "semester_5/software_engineering:program-inspection"
source: https://www.bctengineer.com/q/semester_5/software_engineering/program-inspection
site: BCT Engineering
---

# Why program inspections find errors

Software Engineering · Chapter 7: Verification and validation

- Asked in: 2068 Chaitra, 5+5 marks; year not given, 5+5 marks
- Answer checked by Claude Sonnet 5.5 on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_5/software_engineering/program-inspection
- Whole chapter: https://www.bctengineer.com/md/semester_5/software_engineering/chapter-7

## Question

Explain why program inspection are an effective technique for discovering errors in a program? What types of error are unlikely to be discovered through inspections?

## Short answer

Program inspection is effective because a team statically reads code and can find many unrelated defects in one session, guided by checklists and human knowledge, even before execution. It misses requirements or specification errors, performance issues, timing and concurrency faults, integration problems, usability issues, environment faults, resource leaks, and subtle numeric errors.

## Answer

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.

```text
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.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. Why can an inspection find more errors in one session than a test run can?
   A. It is static, so one error cannot hide (mask) others by crashing the program
   B. It runs the program on more test data
   C. It uses automated tools to run the code faster
   D. It only looks for syntax errors, which are easy to find
   Answer: A. In testing, a crash or wrong output can stop later faults from being reached. Inspection reads the code without running it, so many unrelated defects can be found at once. (Key point: Masking of errors)

2. Which advantage does inspection have over testing for a module that has just been written but not yet integrated?
   A. It needs stubs and drivers to work
   B. It can start without runnable code or a test harness, so defects are found early
   C. It must wait until the whole system is complete
   D. It measures run-time performance of the module
   Answer: B. Inspection needs only the source, so it can begin as soon as a module is written, when defects are cheap to fix. (Key point: Inspecting incomplete programs)

3. Which error is an inspection LEAST likely to discover?
   A. An uninitialised variable
   B. Wrong number of parameters in a call
   C. A race condition that depends on run-time interleaving
   D. A missing break in a switch
   Answer: C. Inspection reads code and cannot observe the program running, so timing and concurrency errors usually escape it. (Key point: Errors inspections miss)

4. Why does an inspection usually fail to detect a wrong specification?
   A. Inspectors never read the specification
   B. Code that matches a wrong specification looks correct when checked against it
   C. Specification errors are always syntax errors
   D. Inspections only check coding standards
   Answer: B. Inspection checks code against its specification, so if the specification itself does not meet real needs, the matching code looks right. This is a validation problem. (Key point: Specification errors)

## Related in other subjects

- [Thread errors and effect of pitch error](https://www.bctengineer.com/question.md?key=semester_3%2Fmetrology%3Ascrew-thread-errors-and-pitch-effect) — Metrology, chapter 12
- [Velocity feedback increases ζ and steady-state error](https://www.bctengineer.com/question.md?key=semester_3%2Fcontrol_systems%3Avelocity-feedback-zeta-sse) — Control Systems, chapter 3
- [Chi-square goodness of fit: Poisson errors](https://www.bctengineer.com/question.md?key=semester_5%2Fprobability_and_statistics%3Achi-square-goodness-fit-poisson-pages) — Probability and Statistics, chapter 7, asked 2×
- [Types of errors and debugging](https://www.bctengineer.com/question.md?key=semester_1%2Fcomputer_programming%3Atypes-of-errors-debugging) — Computer Programming, chapter 2