HKSM

A structured set of test plans, cases, procedures, data, and reports that define how deliverables will be verified and validated against requirements and acceptance criteria. They guide execution and record objective evidence of quality.

Key Points

• Describe what to test, how to test it, and what constitutes pass or fail, aligned to requirements and acceptance criteria.
• Include test strategy, plans, cases, procedures, scripts, data sets, checklists, defect logs, and summary reports.
• Enable traceability from requirements to tests to outcomes, supporting verification and validation.
• Prioritize tests using risk-based thinking to focus on high-impact areas.
• Are living documents under configuration control and change management.
• Support independent review, objective evidence capture, and auditable results.

Quality Objective

Provide consistent, traceable, and reproducible methods to confirm that deliverables meet stated requirements and stakeholder needs, reducing defects and rework before acceptance.

Method Steps

• Define test scope and strategy based on requirements, acceptance criteria, and risks.
• Identify test types needed (e.g., functional, performance, usability, safety, compliance) and their coverage goals.
• Derive test conditions from requirements and models; create traceability links.
• Design test cases with clear steps, expected results, pass-fail criteria, and required data.
• Specify environments, tools, and configurations; define entry and exit criteria.
• Plan roles, responsibilities, schedule, and defect management workflow.
• Peer review the documents; baseline under change control.
• Execute tests, record actual results and evidence, log defects, and retest after fixes.
• Analyze outcomes, assess coverage and residual risk, and produce test summary reports.
• Update documents based on lessons learned and approved changes.

Inputs Needed

• Requirements baseline and acceptance criteria.
• Quality management approach, standards, and metrics.
• Designs, specifications, interfaces, and architecture.
• Risk register and prioritization of high-risk areas.
• Regulatory, compliance, and organizational standards or templates.
• Test tools availability, environments, data privacy and security constraints.
• Lessons learned and historical defect data.

Outputs Produced

• Test strategy and test plan with scope, schedule, roles, and resources.
• Test cases, procedures, scripts, and checklists with expected results.
• Test data sets and environment configuration specifications.
• Requirements traceability matrix linking requirements to tests and results.
• Execution logs, defect/issue records, evidence (screenshots, measurements), and test summary reports.
• Approval records and baselined versions under configuration control.

Acceptance/Control Rules

• Entry criteria: environments ready, data prepared, test items baselined, and prerequisites completed.
• Exit criteria: required tests executed, pass rates met, critical defects resolved, and residual risk accepted.
• Pass-fail defined per test with objective, measurable thresholds.
• Defect severity and priority rules guide triage and retest decisions.
• Independence of testing proportionate to risk (e.g., peer or third-party review).
• Changes to tests follow formal change control and maintain traceability.

Example

A project team preparing a product release creates a test plan outlining scope, roles, and schedule. They design risk-based test cases mapped to high-priority requirements, define expected results, set up a controlled test environment, and prepare anonymized data. During execution, they log defects, capture evidence, and produce a summary report showing coverage, pass rates, unresolved defects, and a recommendation on readiness for acceptance.

Pitfalls

• Vague or missing acceptance criteria leading to subjective pass-fail decisions.
• Poor traceability, making coverage and impact analysis difficult.
• Insufficient or unrealistic test data and environments that do not match production conditions.
• Over-documentation that slows delivery without improving quality, or under-documentation that misses critical tests.
• Late involvement of testers, resulting in rework and gaps in coverage.
• Not updating documents after changes, causing obsolete procedures and false confidence.

PMP Example Question

A sponsor asks how the team will confirm the product meets acceptance criteria before handover. Which artifact best addresses this request?

1. Issue log.
2. Risk register.
3. Communication management plan.
4. Test and evaluation documents.

Correct Answer: D — Test and evaluation documents.

Explanation: Test and evaluation documents define the planned tests, criteria, and evidence collection to verify and validate deliverables before acceptance. The other options do not describe how quality will be confirmed.