Test Plan From Scratch

Requirements

• 1.Define scope (what is being tested) and out-of-scope (what is explicitly excluded) — at least three items in each
• 2.Write entry criteria (minimum three, all objective and binary) and exit criteria (minimum four, including a defect-threshold condition and a coverage-threshold condition)
• 3.Identify at least four test types relevant to this release (e.g. functional, regression, integration, exploratory, accessibility) and justify why each is included — do not list test types that are not applicable
• 4.Build a risk register with at least four risks, each with: description, likelihood (High/Medium/Low), impact (High/Medium/Low), and a one-sentence mitigation or contingency
• 5.Specify test data requirements: name the user types, order states, status-transition sequences, and notification triggers needed, and state how each will be created or sourced
• 6.Define an environment matrix: at least two environments (e.g. staging, pre-production) with a statement of which testing activities run in each
• 7.Include a responsibilities table: name the role accountable for each testing activity (at minimum: test execution, defect triage, accessibility audit, and release sign-off)
• 8.Define a reporting approach: where defects are logged, the reporting cadence, the metric(s) reported, and who provides release sign-off

Starter data

Expected deliverables

• ✓A complete test plan document with all required sections: scope, out-of-scope, test approach, test types with justification, risk register, test data specification, environment matrix, entry criteria, exit criteria, responsibilities table, and reporting approach
• ✓Scope and out-of-scope sections each containing at least three items
• ✓Entry criteria: at least three conditions, all stated as objective binary checks (pass/fail, not 'mostly ready')
• ✓Exit criteria: at least four conditions including one defect-threshold (e.g. zero open Critical/High defects) and one coverage-threshold (e.g. 100% of P1 test cases executed)
• ✓Risk register with at least four risks, each with likelihood, impact, and mitigation
• ✓Test data specification naming specific user types, order states, status-transition sequences, and email notification triggers
• ✓Environment matrix showing which testing activities happen in which environment
• ✓Responsibilities table with named roles for test execution, defect triage, accessibility audit, and release sign-off
• ✓Reporting approach defining cadence, format, metric(s), and sign-off owner

Evaluation rubric

Sample solution outline

Common mistakes

• ✗Listing every possible test type (unit, integration, regression, performance, security, accessibility, usability, localisation) regardless of relevance — a one-week UI feature release does not need a localisation plan; unjustified test types signal that the plan was generated from a template without critical thinking
• ✗Writing exit criteria that are subjective or untestable ('testing is complete when QA is satisfied', 'the feature is stable enough') — exit criteria must be binary and measurable so that any stakeholder can determine pass/fail without consulting QA
• ✗Ignoring the courier API integration risk — the third-party API is the highest-risk dependency in this feature, yet many plans focus only on the UI and omit an integration test strategy or a contingency for API downtime
• ✗Writing a test plan that only QA can follow — responsibilities, reporting, and sign-off must be written for the whole team; a PM or engineering lead should be able to read the plan and know exactly what they are accountable for
• ✗Leaving test data to chance — 'I'll create test data as needed' is not a plan; missing test data on day one of a 5-day testing window blocks the entire team and cannot be recovered without slipping the timeline
• ✗Treating entry criteria as optional or setting them so low they are always met — entry criteria protect QA from spending days testing a broken build; 'feature is mostly done' is not a binary check and cannot protect the team

Submission checklist

• All required sections present in the document: scope, out-of-scope, test approach, test types with justification, risk register, test data, environments, entry criteria, exit criteria, responsibilities, reporting
• Scope and out-of-scope each list at least three items
• At least three entry criteria, all stated as objective binary checks
• At least four exit criteria including one defect-threshold and one coverage-threshold condition
• Risk register with at least four risks, each with likelihood, impact, and a one-sentence mitigation
• Test data specification names specific user types, order states, status-transition sequences, and notification triggers
• Environment matrix shows which activities run in which environment
• Responsibilities table names roles for test execution, defect triage, accessibility audit, and release sign-off
• Reporting approach states cadence, metric(s), defect log location, and sign-off owner

Extension ideas

• +Add a test schedule section with milestone dates derived from a hypothetical sprint calendar (e.g. feature freeze Day 1, regression complete Day 3, sign-off Day 5) and map test activities to the timeline
• +Convert your exit criteria into a concrete Jira saved-filter query or test-run dashboard and describe how you would share it as a daily status link with the PM
• +Write a one-page test summary report as if you had just completed the 5-day testing window — what metrics, defect counts, and risk statements would you present at the release go/no-go meeting?

Related