Question 5 of 8

Question 5 (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part (a) — economic benefits of inspections and informal reviews.

• Defects are found far earlier in the lifecycle than they would be by testing alone (inspections apply to requirements/design documents, before code or test cases even exist), and the cost of fixing a defect grows roughly an order of magnitude per phase it survives undetected, so early detection is the single largest economic lever available.
• Lower cost per defect found — an inspection needs only a small trained team, a checklist, and the document itself; no test environment, test data, or execution infrastructure is required, so the marginal cost of finding one more defect is typically much lower than the equivalent marginal cost in a test phase.
• Fewer defects escape to later phases, which reduces the far more expensive rework, re-test, and (worst case) field-failure/warranty cost that a late-discovered defect causes.
• Knowledge transfer as a side benefit — because inspections involve a small team reading the same artifact together, less-experienced participants absorb domain and design knowledge from more experienced reviewers, reducing future defect-injection rates indirectly.
• Improved estimation and planning — the defect data collected during inspections (defect density by document type, common defect categories) feeds back into more accurate future effort and schedule estimates.

Part (b) — three types of defects identifiable during inspections.

1. Omission defects — something required is simply missing: an un-handled input case in a design, an unaddressed requirement, a missing error-handling branch in code. These are often the hardest defects for testing to find later (you cannot easily test for the absence of something that was never specified), which is exactly why a static, checklist-driven read is effective against them.
2. Standards/consistency defects — the work product violates a documented coding, naming, formatting, or design standard, or is internally inconsistent (two sections of a requirements document that contradict each other). These rarely cause an outright functional failure that testing would catch, yet they directly harm maintainability (Question 8).
3. Logic/functional defects — an incorrect condition, an off-by-one boundary, an incorrectly ordered set of steps, or a design that does not actually satisfy the requirement it claims to. Inspections catch these when a reviewer traces the logic by hand against the specification, often surfacing a defect that would only manifest under a specific, hard-to-construct test input.

(Ambiguity/clarity defects — wording in a requirement or design that different readers could interpret differently — are a commonly cited fourth category and are equally acceptable as one of the "three" if a candidate substitutes it for logic defects.)