Quality Assurance and Verification
This domain tests whether you can plan verification and validation proportionate to risk, manage defects objectively and decide when quality is sufficient to release.
Verification versus validation
- Verification asks whether the product was built right: reviews, static analysis, unit and integration tests.
- Validation asks whether the right product was built: user acceptance testing and business acceptance.
- Test levels run from unit through integration, system and acceptance. Nonfunctional testing covers performance, security, accessibility and resilience.
- Define entry and exit criteria per test level, and trace tests to requirements so coverage is visible.
Defects
Severity is technical impact; priority is business urgency. They are independent. A cosmetic logo misalignment on the login page can be low severity but high priority before a brand launch; a crash in a rarely used report can be high severity but low priority. Track defect leakage to find gaps in earlier testing.
Worked example
A release candidate has 12 open defects: none critical, two high severity in a payment path, and ten low severity cosmetic issues. Exit criteria require zero open high-severity defects in payment. The correct decision is not to release. The reasoning: exit criteria are objective gates, not negotiable opinions; cosmetic defects may be deferred with business approval, but payment defects breach the stated threshold.
Traps
- Using UAT as a regression suite instead of business acceptance.
- Testing only happy paths and ignoring negative, boundary and failure cases.
- Closing defects without retest evidence.
- Releasing without agreed exit criteria, turning quality into a debate.