Inspection in Software Testing: Process, Roles, and a Worked Example

Inspection in software testing is a formal review of a work product without running the software. The item under inspection might be a requirement, design, code change, test plan, or test procedure. Reviewers look for defects in the artifact itself, rather than waiting for an execution to fail.

The useful outcome is a traceable set of findings, corrections, and follow-up decisions. A meeting called an inspection does not provide that evidence by itself. This guide explains the distinction and works through an original CSV-export example, from an ambiguous requirement to a review record and executable test ideas.

Inspection, walkthrough, code review, and testing

The ISTQB Foundation Level syllabus, section 3.2, describes inspection as the most formal review type. It uses a defined process and collects metrics. In that model, the author cannot also be the review leader or scribe.

A code review describes what is examined, not one fixed level of formality. A pull-request discussion may be lightweight; a code inspection can have explicit roles and acceptance criteria. Static analysis tools also examine code without running the application, but their output is not a substitute for people reviewing the requirement and context.

Do not dismiss walkthroughs or technical reviews as activities that cannot find defects. Choose the process for the risk and the evidence needed. For a practical introduction to prioritizing findings, see PracHub's code review guide.

Start with one reviewable artifact

Consider this fictional requirement, version 1:

CSV export:
- A signed-in user can export the records for an account.
- Export up to 1,000 records.
- Missing values are empty.
- A user can retry when a request times out.
- The export should finish quickly.

The text is short, but several independently written implementations could satisfy different interpretations. An automated test suite built from one interpretation could pass while the product still behaves incorrectly.

Before reviewing, attach the intended account-access policy, data schema, and export interface. Identify the exact document revision. Mark unanswered product questions explicitly so reviewers can distinguish missing decisions from contradictions with an existing decision.

In an interview, explain the artifact you are inspecting before listing techniques. Practice reviewing a flawed design document to connect requirements, invariants, reliability, and security without assuming that every issue is a line-level code bug.

Build a defect log with evidence and consequences

For the example above, a useful first-pass log is:

These are review findings, not claims that a particular deployed service is vulnerable. Some are omissions needing a product decision; others may become implementation defects once the intended contract is established.

Give every finding an identifier, artifact location, owner, disposition, and follow-up evidence. Separate confirmed defects from questions and suggestions. Prioritize by consequence: an account-access gap deserves attention before a preference about naming or document layout.

A useful comment might be: “EXP-01, first requirement: account membership is unspecified. A signed-in user could request another account's export under one valid reading. Please define which roles can export and the expected denial behavior.” That gives the author an actionable decision instead of an instruction to “improve security.”

Turn decisions into precise acceptance criteria

Suppose the fictional team resolves those questions as follows. These are illustrative product choices, not a universal export specification:

CSV export, version 2:
- Only owners and administrators of the selected account may export it.
- Check access before creating the job; deny unauthorized requests.
- Export every matching row, up to 1,000 rows. Reject larger results
  explicitly; do not silently truncate them.
- Define the CSV encoding, column order, quoting, and missing-value rules
  in attached fixtures, including commas, quotes, and newlines.
- Reusing a request key for the same account and parameters returns the
  same job. Reusing that key with different parameters is rejected.
- Specify the acknowledgement deadline separately from job completion,
  with the workload and environment for each performance check.

The review should not close merely because the wording changed. Check that each finding has a corresponding decision and that the new wording did not introduce a contradiction. For example, the request-key rule still needs a lifetime and persistence policy before a team can claim reliable retry behavior across restarts.

If the team cannot resolve an issue immediately, record who owns the decision and whether it blocks acceptance. Do not quietly turn “unknown” into “approved.” A documented deferral has a reason and an accountable decision-maker.

Run preparation, discussion, rework, and follow-up

NASA's peer-review and inspection guidance describes planning, preparation, defect recording, rework, and verification. It distinguishes the author's responsibility for corrections from the moderator's responsibility for overseeing the process.

For the export exercise, use that structure this way:

1. Plan: name the document revision, scope, relevant reviewers, and acceptance conditions. Do not include the entire application when the question is one export contract.
2. Prepare independently: have one reviewer trace access decisions, another trace data boundaries, and another examine the proposed tests. Each records findings before group discussion.
3. Discuss and record: compare evidence, combine duplicate reports, and distinguish defects from unresolved questions. Assign extended design work separately so it does not consume the defect-finding session.
4. Rework: the author updates the artifact and links the changed locations to finding IDs.
5. Follow up: verify the corrections against the accepted contract and record remaining actions before accepting, conditionally accepting, or returning the artifact for further work.

Make responsibilities visible. Someone must facilitate the discussion, someone must preserve its record, and each correction needs an owner and verifier. Formal processes may prescribe additional roles and constraints; a small team's adapted exercise should not be presented as compliance with a standard it has not followed.

Inspect the test plan, then execute the tests

The version-2 requirement suggests concrete test ideas:

• Attempt an export as an authorized account owner, an authorized administrator, an unrelated signed-in user, and an unauthenticated client.
• Exercise 0, 1, 999, 1,000, and 1,001 matching rows, checking the stated empty-result and over-limit policies.
• Compare output with fixtures containing commas, quotes, line breaks, non-ASCII text, and missing values. Resolve whether a missing value must be distinguishable from an empty string.
• Repeat a request after a simulated timeout. Check same-key/same-parameters and same-key/different-parameters behavior, including the agreed key lifetime.
• Observe acknowledgement and completion separately under the specified workload. Do not pass a completion target by measuring only job creation.

Inspect these cases for missing preconditions and expected results before implementing them. A case saying “test permissions” is not yet a reproducible check. Name the caller, account membership, requested resource, expected result, and evidence that denied requests created no export job.

Then run the software. Review may identify a race in the job-creation design; execution can exercise competing requests and observe the actual outcome. Saying inspection can never find concurrency defects is too strong. Equally, reading a plausible design does not establish its latency, deployment compatibility, or behavior under load.

For a smaller algorithmic exercise, develop a test plan and TDD workflow for word search. Use its public prompt to practice deriving cases and expected results, rather than treating the implementation as the source of truth. Broader preparation is available in the QA and SDET interview guide.

Interpret inspection metrics carefully

Record effort, reviewed scope, finding categories, serious unresolved issues, and verified corrections. Compare like artifacts and comparable review goals. A lower finding count could mean a better artifact, weaker preparation, or incomplete coverage; attendance and pages reviewed do not resolve that ambiguity.

Historical research offers useful context for this distinction. A NASA-hosted analysis of inspection parameters examines relationships between pace and defect-finding outcomes. Its results should inform investigation of your own process, not become a universal pages-per-hour target.

A separate NASA report on inspection and testing data reports an average of 64% of software defects removed through inspections across eight studied projects. That is a result for those projects. It does not establish a guaranteed removal rate or justify eliminating two-thirds of another team's testing budget. The report's testing-effort discussion uses remaining defects as an approximation, not a direct measurement of every team's future workload.

Use metrics to improve the process rather than rank individuals by how many defects they report. Otherwise, reviewers can be rewarded for splitting duplicates or producing low-value findings instead of clarifying important risks.

Apply the same scrutiny to AI-generated artifacts

Review the requirement, implementation, and tests independently. If all three repeat the same unsupported assumption, agreement between them is weak evidence. For the export example, tests that assert a 1,000-row truncation policy do not establish that truncation was the intended product behavior.

The 2025 Stack Overflow Developer Survey reported that 46% of respondents to its AI-accuracy question distrusted the output and 33% trusted it. These are reported attitudes, not a measured defect rate for generated code or proof that any specific tool is unsafe.

Ask an assistant to propose edge cases or organize findings, then check the underlying artifact and evidence. Keep sensitive review materials within the team's approved tools and access rules. A fluent explanation is not a verified correction.

A concise interview answer

“Inspection is a formal static review of an artifact. I would fix the revision and scope, prepare independently against the requirement, record evidence-backed findings, have the author rework the artifact, and verify corrections against exit criteria. For an export feature, I would inspect account access, record limits, output rules, and retries before implementing tests, then execute boundary, failure, concurrency, and performance checks. Inspection and execution provide different evidence.”

Follow that answer with one defect you can explain from evidence through correction to verification. That shows how the process changes the work product, rather than merely naming its stages.

Keep practicing

• Review and improve a flawed design document
• Develop a test plan and TDD for word search
• Code review: finding bugs and explaining trade-offs
• QA and SDET interview preparation