Quality Management: Requirements, Reviews and Acceptance
What this domain tests
Quality Management tests your ability to define quality as fitness for purpose against agreed requirements, and to design the checks that prove it. Expect items on the quality plan, review versus test, independence, and acceptance criteria at decision points.
Core rules
- Quality means meeting the agreed requirements and being fit for the intended use - not “as good as possible”.
- The quality plan states, per deliverable, the acceptance criteria, the check to be applied (review, test, inspection, audit), who performs it and when.
- Verification asks whether the deliverable is built correctly; validation asks whether it is the right deliverable for the objective. Both belong in the plan.
- Reviews are cheaper than tests and tests are cheaper than repairing in production; place checks as early as they can be effective.
- Quality assurance is the independent check on the process; quality control is the check on the product. They are not the same, and neither is simply “testing at the end”.
- Deliverables are formally accepted before a phase gate closes. Acceptance without recorded criteria is not acceptance.
Worked example
A finance project plans acceptance as “user acceptance test in week 40”. Reasoning: too late and too narrow. The quality plan should specify the requirements document reviewed by finance and IT in week 6, a design review in week 12, a technical test against interface specifications in week 24, and the user acceptance test in week 40. A defect found in the week-6 review costs a conversation; the same defect found in week 40 costs rework, delay and re-testing - which is the reasoning the exam wants.
Traps that cost marks
- Treating quality as a final testing phase rather than checks placed throughout.
- Confusing QA (process, independent) with QC (product, by the makers).
- Acceptance criteria that are subjective (“user-friendly”, “professional look”).
- Closing a phase without documented acceptance of its deliverables.