02 Test Plan

Test Plan Skill

Use When

• Produce or update a detailed test plan from an approved SRS, test strategy, and implementation scope.
• Resolve test-case, test-data, environment, schedule, ownership, traceability, and exit-evidence decisions.
• Prepare an executable handoff for QA engineers, developers, and the release owner.

Do Not Use When

• The task sets programme-level test policy, levels, or risk posture; use test-strategy and consume it here.
• Required project evidence or decision authority is unavailable and the requester expects a pass, release, certification, or production change.

Required Inputs

Outputs

Evidence Produced

Capability and Permission Boundaries

• Minimum capabilities: read and search the authorised project sources. Execution is optional and limited to non-destructive validation.
• Assessment and planning default to read-only. Create or edit the named project document only when the request explicitly authorises it. Production mutation, publishing, destructive action, spending, external communication, or certification claims require separate explicit authority.
• Treat secrets, tenant data, incident evidence, and financial records as least-privilege inputs; expose only the minimum evidence needed for review.

Degraded Mode

If files, execution, network, rendering, environment access, fonts, or current evidence are unavailable, return the narrowest useful draft plus a gap register. Label affected checks not assessed, retain the intended acceptance oracle, and state who must supply or verify the missing evidence. Never convert an unavailable check into a pass.

Decision Rules

Workflow

1. Confirm the named deliverable, consumer, scope, environment, authority, and neighbouring-skill boundary.
2. Inventory required sources and validate provenance, freshness, internal consistency, and missing inputs. Stop the affected branch on a mandatory gap.
3. Extract traceable requirements, invariants, risks, and measurable acceptance criteria; record conflicts before choosing a design or procedure.
4. Apply the decision rules and the domain workflow below. For a failed branch, preserve evidence, choose the documented recovery path, or escalate to the named owner.
5. Draft the artefact, decision register, and evidence record together. Do not defer failure handling, rollback, security, tenancy, accessibility, or operational ownership.
6. Run available checks, review every result, repair failures, and hand off only when acceptance is observable. If recovery fails or authority is exceeded, stop and escalate without mutation.

Quality Standards

• Ground every section in a named project source, decision, measured result, or accountable owner.
• Give each requirement or procedure a deterministic oracle that another reviewer can reproduce.
• Keep assumptions, exclusions, degraded checks, residual risks, and waivers visible at handoff.
• Preserve the domain invariants and more specific controls in the existing workflow below; this contract does not replace them.
• Run the repository anti-AI-slop gate: remove filler, verify named standards and dependencies, and retain purposeful domain detail.

Anti-Patterns

• Copying a generic template without mapping it to project sources. Fix: attach each section to an approved requirement, configuration, risk, or owner.
• Choosing a threshold because it is common practice. Fix: derive it from a requirement, measured baseline, risk decision, or current verified source.
• Reporting an inaccessible or unexecuted check as passed. Fix: mark it not assessed, preserve the oracle, and name the verifier.
• Rewriting the test-strategy inside the plan. Fix: reference its policy and use this artefact for executable cases, resources, sequence, and evidence.
• Omitting failure, rollback, empty-state, security, tenancy, or escalation behaviour. Fix: specify the trigger, safe action, verification, and owner for each applicable case.
• Mutating a repository, environment, tenant, ledger, or external system while drafting guidance. Fix: remain read-only until the exact mutation and authority are explicit.
• Claiming compliance, certification, readiness, or release from prose alone. Fix: require source-attributed evidence and a named acceptance decision.

Worked Example

Given FR-PAY-014 and a payment retry design, map successful, declined, timeout, duplicate-callback, and reconciliation paths to named cases. Record required fixtures and expected ledger or status outcomes. Stop if the retry authority or idempotency contract conflicts; resume after the accountable owner records the controlling decision.

References

• logic.prompt - load only when its template, logic, or detail is needed.
• README.md - load only when its template, logic, or detail is needed.

Overview

This is the second skill in Phase 05 (Testing Documentation). It transforms the SRS functional and non-functional requirements into a detailed test plan containing test cases, test data definitions, schedule, resource allocation, and a requirement-to-test traceability matrix. Every "shall" statement in SRS Section 3.2 becomes a test case. The output conforms to BS ISO/IEC/IEEE 29119-3 Sections 7-8 and references the deterministic checklist for artifact completeness.

When to Use

• After 01-test-strategy completes and Test_Strategy.md exists in projects/<ProjectName>/<phase>/<document>/ with test levels, types, and criteria.
• When SRS_Draft.md exists in projects/<ProjectName>/<phase>/<document>/ with functional requirements containing "shall" statements.
• Optionally, when acceptance_criteria.md exists in projects/<ProjectName>/<phase>/<document>/ for agile projects requiring acceptance-test mapping.

Quick Reference

Input Files

Output Files

Core Instructions

Follow these nine steps in order. Halt and notify the user if a required input file is missing.

Step 1: Read Context Files

Read SRS_Draft.md and Test_Strategy.md from projects/<ProjectName>/<phase>/<document>/. Optionally read acceptance_criteria.md from projects/<ProjectName>/<phase>/<document>/ if it exists. Log the absolute path of each file read. If any required file is missing, halt execution and report the gap.

Step 2: Extract Testable Requirements

Parse SRS Section 3.2 and extract every "shall" statement as a testable requirement. Assign each requirement a unique identifier (e.g., REQ-FUNC-001). Log the total count of extracted requirements.

Step 3: Map Acceptance Criteria

If acceptance_criteria.md exists, map each acceptance criterion to its corresponding SRS requirement and note which test cases shall validate it at the UAT level. If the file does not exist, skip this step and note that UAT cases derive from SRS requirements directly.

Step 4: Define Test Design Specification & Test Case Format

Document the selected test design techniques (equivalence partitioning, boundary values, state machine testing, decision tables, use case testing) and cite the applicable 29119-3 clause (§7.3.3). Each technique shall reference the requirements it exercises.

Establish the test case format using the nine normative 29119-3 fields: TC-ID, Objective/Purpose, Priority, Traceability to requirement ID, Preconditions, Test Input, Expected Result (with deterministic pass/fail), Actual Result (filled at execution), and Test Result (Pass/Incident). Include Steps (numbered actions) beneath the structured fields.

Step 5: Generate Functional Test Cases

For each functional requirement extracted in Step 2, generate one or more test cases. Each test case shall define preconditions, sequential steps, and a deterministic expected result. Group test cases by SRS feature (Section 3.2.x subsections).

Step 6: Generate Non-Functional Test Cases

Generate test cases for non-functional requirements: Performance tests from SRS Section 3.3 (response time, throughput, capacity), Security tests from SRS Section 3.5.3 (authentication, authorization, data protection). Each NFR test case shall include measurable acceptance thresholds.

Step 7: Define Test Data Requirements

For each test case group, define the test data required: data entities, volume, generation method (manual, scripted, anonymized production data), and precondition data state. Identify shared test data dependencies across test case groups.

Step 8: Define Schedule and Resource Allocation

Define the test execution schedule: phases aligned with Test_Strategy.md test levels, estimated duration per phase, resource assignments (roles, not named individuals), and dependencies between phases. Identify parallel execution opportunities.

Step 9: Generate Traceability Matrix and Write Output

Generate a requirement-to-test traceability matrix mapping every REQ-ID to its TC-IDs, confirming full coverage. Flag any requirements without test cases as coverage gaps. Before writing output, verify the deterministic gate in ../references/29119-deterministic-checks.md has been satisfied (mandatory artifact tree, clause annotations, entry/exit criteria). Write the completed document to projects/<ProjectName>/<phase>/<document>/Test_Plan.md. Log the total count of test cases, coverage percentage, and any gaps.

Output Format

The generated Test_Plan.md shall contain these sections in order: Document Header (project name, date, version, standards), 1. Test Scope, 2. Test Case Summary Table, 3. Detailed Test Cases (grouped by feature), 4. Test Data, 5. Schedule, 6. Resources, 7. Traceability Matrix, Appendix A: Coverage Gap Report.

Final Step: Write manifest.md

After generating all section files, create (or overwrite) manifest.md in this document's directory listing the section files in the correct assembly order:

# Document Manifest — Test Plan
# Generated by test-plan. Edit to reorder or exclude sections before building.
01-test-scope.md
02-test-cases.md
03-test-data.md
04-schedule.md
05-resources.md
06-traceability.md
07-coverage-gaps.md

This ensures scripts/build-doc.sh assembles sections in the intended order rather than alphabetical fallback.

Common Pitfalls

Verification Checklist

• Test_Plan.md exists in projects/<ProjectName>/<phase>/<document>/ with all seven sections populated.
• Every "shall" statement in SRS Section 3.2 has at least one corresponding test case.
• Test cases include preconditions, sequential steps, and deterministic expected results.
• NFR test cases include measurable acceptance thresholds from SRS Sections 3.3 and 3.5.
• Test data requirements are defined for each test case group.
• Schedule aligns with test levels from Test_Strategy.md.
• Traceability matrix achieves full requirement coverage; gaps are flagged in the appendix.

Integration

Standards

• BS ISO/IEC/IEEE 29119-3 -- Current international standard for test documentation; governs project-level test plans, traceability, and required artifact set (Sections 7-8).

Resources

• logic.prompt -- Executable prompt containing the step-by-step test plan generation logic.
• README.md -- Quick-start guide for this skill.

Worked example

See examples/representative/.