QA Testing Checklist Template

Phase 1: Test Planning & Strategy

The test plan is developed from the requirements or specification — ideally in parallel with the design phase, not after the build is complete. A test plan written after the build is a test plan at risk of being shaped by what was built rather than what was required.

• Define the test scope — what is being tested; what is explicitly out of scope; what testing was done at earlier stages that this test phase builds on
• Define test objectives and success criteria — what does “pass” look like? The Go/No-Go criteria defined now, before testing begins
• Select test types — based on the risk profile of the product/feature; which test types are required? Functional, regression, integration, performance, security, UAT (software); functional, environmental, durability, certification (physical)
• Identify test resources — who will conduct each test type; what equipment, tools, and environments are required; availability confirmed
• Estimate the testing timeline — realistic time for each test type; factored into the project schedule before development starts

Phase 2: Test Case Development

• Write test cases from the specification — not from the implementation; each test case has: a reference to the requirement it tests; a precondition; the test steps; the expected result; and the pass/fail criterion
• Cover positive and negative cases — test that the product does what it should (positive) AND that it handles incorrect inputs, boundary conditions, and error scenarios correctly (negative)
• Cover edge cases — boundary values, empty inputs, maximum values, simultaneous operations, unusual sequences
• Review test cases — with the product owner or design engineer; confirm every requirement is covered by at least one test case
• Confirm traceability — every requirement maps to at least one test case; no requirement goes untested (unacceptable for safety-critical or compliance requirements)

Phase 3: Test Environment Setup

• Software test environment — representative of production; separate from development and production; test data prepared; all required integrations configured
• Physical test equipment — calibrated; available for the test dates; any environmental test chambers or specialist equipment booked in advance
• Test data prepared (software) — representative of real-world data volumes and types; including edge-case data; compliant with data privacy requirements (anonymised where required)
• Reference samples prepared (physical) — approved samples or golden units for comparison

Phase 4: Test Execution

• Execute functional tests — following each test case; recording actual result against expected result; pass or fail for each
• Execute regression tests — to confirm the change has not broken previously-passing functionality; automated regression suite where available
• Execute integration tests — confirming interfaces between components, systems, or subsystems work correctly together
• Execute performance tests — response times under expected load (software); output performance under rated conditions (physical); confirmed against specification
• Execute edge case and negative tests — boundary values, invalid inputs, error conditions; do they produce the expected controlled failure or error response?
• Execute UAT (software) or regulatory/certification tests (physical) — by real users (UAT) or by a certified test lab (regulatory testing)
• Log every defect found — following the defect classification and logging process; every test case that produces an unexpected result generates a defect report

Phase 5: Defect Management During Testing

• Triage all defects — severity and priority assigned; duplicates identified and linked; confirmed as defects (not misunderstood requirements)
• Critical/Major defects block testing progression — until resolved; the test cycle does not complete until all Critical and Major defects are resolved and re-tested
• Retest all fixed defects — by the tester who found the original defect (where possible); following the original test steps; confirming the fix is effective and has not introduced regressions

Phase 6: Test Sign-Off & Entry to Next Phase

The test sign-off is a formal, criteria-based decision — not a judgment call made under schedule pressure. The criteria are the same ones defined in Phase 1. If the criteria are not met, the product does not advance to the next phase.

• Assess against the Go/No-Go criteria — defined in Phase 1; all required test types completed, all test cases executed, no Critical or Major defects open
• Produce the test summary report — total test cases executed, pass rate, defects by severity, open defects, and the sign-off recommendation
• Obtain sign-off — from the QA lead and the product owner or engineering lead; written confirmation that the product meets the test criteria and is ready to advance
• Archive all test artefacts — test plan, test cases, test results, defect records, and sign-off document; in the product or project record