Draft a Test Plan and Traceability Matrix from Product Context

Tier: Foundation · Workflow area: Test design & planning

This playbook produces a reviewable test plan and a requirements-to-tests traceability matrix from a template, a feature description, and your constraints. The model fills sections and builds tables; every risk assessment, priority, and go/no-go criterion is authored or explicitly confirmed by you — and labeled that way.

When to use

• A release or feature large enough to demand a written planclient deliverables, regulated contexts, cross-team programs.
• Audit or client-facing traceability requirementsyou must show which test covers which requirement, on paper.
• Onboarding a new projectdrafting the plan forces the model (and you) to surface what context is missing.

When NOT to use:

• Lightweight in-team testing where a one-page charter or a checklist serves better — a generated 14-section plan nobody reads is process theater.
• When you lack the product knowledge to check the draft. A plausible plan you cannot verify is worse than no plan; do a product walkthrough first.

Prerequisites

• Your organization's plan templateor agree on a lightweight section list before generating; the model must fill your structure, not invent one.
• A requirements list with stable IDsthe traceability matrix is only as real as the IDs it references.
• An approved assistant per your data policy, since plans carry scope, dates, and sometimes client names.
• A named reviewer who will actually read the draft — a plan without a committed reviewer is a document, not a plan.

The recipe

1. 1.

   Gather the ingredients. Your organization's test plan template (or IEEE 829-lite section list), the feature/release scope, the requirement list with IDs, known environments, team capacity, and hard dates. The quality of the draft is capped by this packet.

2. 2.

   Prompt for a draft with explicit human-decision placeholders. This is the structural trick — force the model to leave the judgment slots empty:

   Copy

   Draft a test plan using EXACTLY this template: [paste section headings].
   Context: [feature scope, requirements list with IDs, environments, dates,
   team of 2 QA + 1 SDET].
   
   Rules:
   - Fill structural/factual sections fully (scope, environments, schedule
     skeleton, deliverables, entry criteria).
   - For every judgment call — risk ratings, priority order, out-of-scope
     decisions, exit criteria thresholds — write the options with trade-offs
     and mark the line [HUMAN DECISION].
   - Do not invent requirements, dates, or tool names not in the context.
   

3. 3.

   Resolve every [HUMAN DECISION] yourself. Search the draft and replace each placeholder with your call:

   Copy

   grep -n "HUMAN DECISION" test-plan-draft.md
   

   A draft with zero placeholders is a red flag — the model made your risk calls for you. Regenerate with the rules restated.

4. 4.

   Generate the traceability matrix as a table.

   Copy

   Build a traceability matrix as a markdown table from these requirements and
   these planned test groups: [paste both].
   Columns: Req ID | Requirement summary | Test case ID(s) | Coverage type
   (positive/negative/boundary) | Status (Planned).
   List any requirement with NO covering test under "UNCOVERED" below the
   table. List any test with no requirement under "ORPHAN TESTS".
   

   The UNCOVERED and ORPHAN lists are the real product — a good run surfaces exactly the gaps you would have found in week three:

   Copy

   UNCOVERED:
   - REQ-108 (data retention purge after 90 days) — no planned test group
   - REQ-112 (concurrent edit conflict handling) — no planned test group
   ORPHAN TESTS:
   - TG-14 (legacy CSV export) — no requirement in scope references CSV
   

5. 5.

   Verify the matrix against the sources, sampled. Pick five random rows and confirm the test group genuinely covers the requirement — models will happily map REQ-108 to a test that mentions retention without testing the purge. Fix mappings by hand; the matrix is a claims document and you are signing it.

6. 6.

   Circulate for review with authorship labeled. State in the document which sections were AI-drafted and human-reviewed — in client and audit contexts this disclosure is increasingly contractual, and it costs you nothing when the review was real.

Make it yours

• Xray/Jira-native traceabilityskip the markdown matrix; have the model emit a CSV of Req-to-Test links and import, then use built-in coverage reports as your living matrix. The UNCOVERED prompt still earns its keep as a pre-import check.
• Claude Code in a docs-as-code repoplans living in git get drafted in-branch; reviewers comment on the PR, and the traceability matrix regenerates from requirement files on every change, with git diff showing exactly what coverage moved.
• Regulated/medical variantkeep the template's mandated sections verbatim, use AI only for first-draft prose within sections, and route through your document control process; the [HUMAN DECISION] discipline maps cleanly onto required signatory review.

Quality check

• Zero unresolved [HUMAN DECISION] markersand each resolution is yours, written in your words with a reason.
• Matrix spot-check passedfive sampled rows verified against actual requirement and test content, not just matching keywords.
• UNCOVERED list is empty or explicitly acceptedeach uncovered requirement carries a signed-off rationale, not silence.
• No invented factsdates, environment names, and tool versions all trace to your context packet; grep for tool names you never mentioned.
• Exit criteria are measurable"regression suite ≥98% pass, zero open P1s" not "testing is complete"; the model defaults to the latter.
• The plan fits the efforta two-week feature got pages, not a novella; cut sections the template allows you to cut.