qa_test_plan_writing v1.0.0

name: "qa_test_plan_writing" description: "Write a QA test plan for a feature before testing starts: scope and exclusions, test cases tied to requirements, entry and exit criteria, environments and test data needs, defect workflow, and the sign-off that says testing is done. Use when planning testing for a feature, release, or sprint, reviewing a test plan for gaps, or deciding whether testing is ready to start or finish."

QA Test Plan Writing

Purpose

Produce a test plan a tester who did not write it can execute without asking what was meant. The plan states what will be tested, what will not, how cases trace to requirements, when testing may start, when it is done, what happens when a defect is found, and who signs off. Tool neutral on purpose: it works in a document, a wiki page, or a test management tool.

Workflow

1. Gather the test basis before writing anything. Collect the requirements or user stories with IDs, acceptance criteria, design notes, and any prior defect history for the area. If a requirement has no ID, give it a local ID in the plan and note the source. A case with no requirement behind it is either a risk based case, labelled as such, or it gets cut.

1. Set scope and exclusions in plain lists. Name the test items with versions where known, the features to be tested, and the features not to be tested with a reason for each exclusion, such as covered by another plan, third party owned, or deferred to a later release. Exclusions without reasons invite scope arguments later. Add the top product risks and project risks, and state which scope items exist because of each risk.

1. Choose the approach and name the design techniques per area. State the test levels in scope (for example system testing and user acceptance), the test types (functional, regression, accessibility, performance where relevant), and which technique drives case design for each feature. Use the guide in references/case-writing-rules.md: equivalence partitioning and boundary value analysis for ranges and fields, decision tables for combined business rules, state transition testing for workflows with defined states, use case testing for end to end journeys, and error guessing or exploratory charters to supplement, not replace, the structured techniques.

1. Write the test cases and build the traceability matrix. Follow the case format and rules in references/case-writing-rules.md. One objective per case, numbered steps, concrete data, an expected result that can be judged pass or fail without opinion. Link every case to at least one requirement ID, then build the matrix: requirement, linked cases, coverage status. Any requirement with no case is a visible gap, either planned, waived with a name attached, or blocking. Run bin/plan_check.py on the plan file to catch missing sections, cases with no requirement link, and requirements with no case.

1. Write entry, exit, suspension, and resumption criteria as checkable conditions, not intentions. Entry criteria say when execution may start, for example test environment ready and verified, test data loaded, build deployed and smoke checked, entry level cases reviewed. Exit criteria say when testing is done, for example all planned cases executed, agreed coverage reached, no open defects at the top severity level, and remaining defects recorded with a disposition. Suspension criteria say when testing stops, for example the build blocks the main flows or the environment is down, and resumption criteria say what must be true to restart. Every threshold is a number or a yes or no check. Mark thresholds the team chose for this feature as team decisions, not as industry standards.

1. Specify environments and test data as a shopping list someone can act on. For each environment: purpose, build or version, browser or device coverage, integrations and whether they are live, stubbed, or sandboxed, access accounts and roles, and who owns setup. For test data: what states are needed (new user, expired subscription, empty cart, large order), the source for each set (synthetic, masked production subset, or created through the product UI or API), volume where it matters, what must be isolated per run versus reusable, and the refresh or reset method. Never plan to use unmasked production personal data. If production data is the source, the plan states the masking or anonymisation step and who verified it.

1. Define the defect workflow before the first defect appears. State where defects are logged, the required fields (summary, steps to reproduce, expected and actual result, environment, affected area, severity, evidence), the lifecycle statuses the team will use, and the triage rhythm. Keep severity and priority separate: severity is the functional impact, set by the person who logs the defect; priority is the urgency to fix, set in triage with the product side. State the fix, retest, regression, and closure rules, plus what deferred, duplicate, rejected, and needs more info mean in this team. See references/plan-template.md for a default workflow to adapt.

1. Close the plan with schedule, deliverables, and sign-off. List milestones and dependencies in date or sprint terms the team already uses, the deliverables testing will produce (plan, cases, traceability matrix, defect reports, test summary report), and the approvals table: who approves the plan, who accepts the exit report, and what happens when exit criteria are not met but a release decision is made anyway. That last line matters. A waiver is a named decision with a date, not a quiet pass.

Output Contract

Deliver one test plan that contains all of the following, in this order. Use references/plan-template.md as the fill in structure.

1. Header: plan ID, feature name, version, author, date, references to the test basis.
2. Scope: test items, features to be tested, features not to be tested with reasons, risks.
3. Approach: levels, types, design techniques per area, test case count estimate by priority.
4. Test cases or a link to them, plus the requirements traceability matrix.
5. Entry, exit, suspension, and resumption criteria, each checkable.
6. Environments and test data: setup list, owners, data sets, masking note, refresh method.
7. Defect workflow: required fields, severity and priority definitions, statuses, triage cadence, retest and closure rules.
8. Schedule, deliverables, metrics to be collected, and the sign-off table with named approvers.

A plan missing any of the eight is a draft. Say so at the top of the document and name what is missing.

Operating Rules

1. Verify claims against the test basis. If the requirement does not say it, the plan does not assert it as expected behaviour. Mark open questions as open questions with an owner.
2. No invented thresholds. Coverage targets, defect counts, and pass rates in a plan are team decisions for that feature. Present the worked example numbers in references/worked-example.md as examples only.
3. Traceability is not paperwork. If a requirement changes, the matrix shows which cases to recheck. If it cannot do that, fix the links before execution starts.
4. Write cases for a stranger. Preconditions, data, and steps carry everything execution needs. Tribal knowledge in a case is a defect in the plan.
5. Keep SKILL.md level detail here and bulk in references. The full template is in references/plan-template.md, case rules in references/case-writing-rules.md, and a complete worked feature plan in references/worked-example.md.
6. Structure follows recognised practice without copying it blind. The section set aligns with IEEE 829-2008 and ISO/IEC/IEEE 29119-3, and the terminology for test plan, entry criteria, and exit criteria follows the ISTQB glossary. Adapt section weight to the size of the feature: a small feature gets a short plan with all eight parts, not a long plan with padding.