Testing, Verification, and Quality Assurance
Domain 5 covers test levels, design techniques, coverage criteria and the QA versus QC distinction. Expect to design test cases for a small input domain, map levels to the V-model, and interpret a coverage figure correctly.
Levels, types and static techniques
Levels run unit, integration, system, acceptance, mapped respectively to detailed design, architecture, requirements and user needs. Black-box techniques are specification-driven: equivalence partitioning, boundary value analysis, decision tables, state transition testing and pairwise combination. White-box techniques are code-driven: statement, branch/decision, condition, MC/DC and path coverage. Verification asks whether the product conforms to its specification; validation asks whether it satisfies the user need. Quality assurance is process-oriented and preventive; quality control and testing are product-oriented and detective. Static techniques such as inspections, reviews and static analysis find defects without executing code, often more cheaply than dynamic testing.
Coverage
Statement coverage is subsumed by branch coverage, but full branch coverage does not guarantee every condition in a compound predicate is evaluated, which is why MC/DC exists. No practical criterion guarantees all paths through loops. Coverage measures executed code, not correctness: a suite can reach 100 percent branch coverage and still miss a wrong requirement.
Worked example
An input field accepts an integer age from 18 to 65 inclusive and rejects everything else. Equivalence classes: valid 18 to 65, invalid below 18, invalid above 65, non-numeric. Boundary values for the valid class are 18 and 65 (valid) and 17 and 66 (invalid); add 25 as the interior valid representative. Reasoning: off-by-one defects cluster at relational operators, so testing 18 and 17 distinguishes <= from <, while the interior value checks that normal processing works at all. A decision table then covers combinations once a second condition, such as membership status, is added.
Traps that cost marks
- Equating QA with testing; QA is the process system that prevents defects.
- Believing high coverage implies few defects.
- Omitting just-outside boundary values, exactly where defects live.
- Confusing severity (impact) with priority (fix order); a crash in an unused feature is high severity, low priority.
- Assuming unit tests and mocks replace integration or system testing.
- Using a mock where a stub suffices, then asserting on internal implementation details.