Qa Test Plan

QA Test Plan

Generates a structured QA test plan from completed requirements artifacts. Produces test suites that map directly to business requirements and user personas so QA teams know exactly what to test during each delivery timeline QA round.

Prerequisites

• {base_directory}/requirements/business-requirements.yaml (output from /business-requirements-interview)
• {base_directory}/requirements/technical-requirements.yaml (output from /technical-requirements-interview)

Usage

/qa-test-plan [base-directory]

If no directory is provided, auto-detect by looking for requirements/business-requirements.yaml in the current directory.

If not found, prompt the user: "Where are your requirements documents located?"

Wait for the user to provide a path before proceeding. Store as base_directory.

Process

Step 1: Determine Base Directory and Load Requirements

If no directory parameter was provided, check if requirements/business-requirements.yaml exists in the current directory.

• If found, use current directory as base_directory
• If not found, prompt: "Where are your requirements documents located?" and wait for user response

Once base_directory is determined, read both requirements files from {base_directory}/requirements/. Extract:

From `business-requirements.yaml`:

• Functional requirements and user stories
• User personas and their primary use cases
• Success criteria and metrics
• Known constraints and edge conditions

From `technical-requirements.yaml`:

• API surface (endpoints, inputs, outputs)
• Authentication and authorization model
• Non-functional requirements (performance targets, uptime SLAs)
• Data model constraints (required fields, uniqueness, formats)
• Security requirements

Step 2: Identify Test Suites

Group test coverage into suites. Each suite maps to a coherent functional area (not to individual milestones). Derive suites directly from the requirements — do not invent features not present in the source documents.

Standard suite categories to consider (include only those applicable):

Step 3: Generate Test Cases per Suite

For each suite, write test cases covering:

• Positive — happy path, expected successful outcomes
• Negative — invalid inputs, unauthorized access, missing required fields
• Edge — boundary values, empty states, concurrent operations, large payloads
• Security — injection, unauthorized access escalation, token/session misuse
• Performance — response time under expected load (only when targets are specified)

Each test case must include:

• id — unique, scoped to suite (e.g. tc-auth-001)
• name — plain-language description of what is being tested
• type — positive | negative | edge | security | performance
• priority — high | medium | low
• high: covers a success criterion or a named persona's primary use case
• medium: covers a secondary flow or validation rule
• low: covers an edge/corner case unlikely to affect typical users
• preconditions — system state required before executing the test
• steps — numbered, concrete actions
• expected_result — specific, verifiable outcome
• requirement_refs — IDs of the business/technical requirements this case validates
• tags — optional labels for filtering (e.g. [smoke, regression, auth])

Step 4: Compute Coverage

Calculate coverage metrics:

• Functional coverage — percentage of named functional requirements with at least one high-priority test case
• Persona coverage — percentage of user personas whose primary use case has a positive test case
• Non-functional coverage — boolean per NFR category (performance, security, etc.) — at least one test case exists

Flag any functional requirement with no test case as a coverage gap.

Step 5: Generate qa-test-plan.yaml

Write {base_directory}/delivery/qa-test-plan.yaml.

Create directory if it doesn't exist:

mkdir -p {base_directory}/delivery

Step 6: Gap Analysis

After generating the file, report inline:

## QA Test Plan Gap Analysis

**Project:** [name]
**Test Suites:** [n]
**Total Test Cases:** [n] ([n] high / [n] medium / [n] low)
**Functional Coverage:** [n]% ([n]/[n] requirements have high-priority cases)
**Persona Coverage:** [n]% ([n]/[n] personas covered)

**NFR Coverage:**
[✓ / ✗] Performance tests present
[✓ / ✗] Security tests present
[✓ / ✗] Integration tests present

**Gaps:**
- [requirement or persona with no coverage, if any]

**Recommendations:** [none / list]

Output Format

qa-test-plan.yaml Schema

The output document includes: version, project, generated, sources (reference file paths), summary (test counts by priority, coverage metrics), and test_suites (each with id (ts-slug), name, description, requirement_refs, and test_cases). Each test case has: id (tc-suite-nnn), name, type (positive/negative/edge/security/performance), priority (high/medium/low), preconditions, steps, expected_result, requirement_refs, and optional tags.

See [references/output-spec.md](references/output-spec.md) for the complete document specification with all fields, coverage calculation rules, and test case structure.

See [references/example.yaml](references/example.yaml) for a full example.

Example Output

See [references/example.yaml](references/example.yaml) for a complete sample QA test plan.

QA Test Plan YAML Specification

Document Type: qa-test-plan.yaml Version: 1.0.0 Generated By: qa-test-plan skill Purpose: Structured test plan keyed to functional requirements and user personas, covering positive, negative, edge, security, and performance cases. Generated from business and technical requirements for use during delivery timeline QA phases.

---

Document Structure

Root Level

version: string                    # Semantic version (required, format: "X.Y.Z")
project: string                    # Project name (required)
generated: string                  # ISO 8601 timestamp (required)
sources:
  business_requirements: string    # Filename of business requirements (required)
  technical_requirements: string   # Filename of technical requirements (required)

Validation Rules:

• version: Must be semantic version format (e.g., "1.0.0")
• project: 3-100 characters, matches source requirements
• generated: ISO 8601 format (e.g., "2026-04-16T10:30:00Z")
• sources.business_requirements: Filename (typically "business-requirements.yaml")
• sources.technical_requirements: Filename (typically "technical-requirements.yaml")

Summary Section

summary:
  total_test_suites: integer       # Number of test suites (required, ≥1)
  total_test_cases: integer        # Number of test cases across all suites (required, ≥1)
  by_priority:
    high: integer                  # Count of high-priority cases (required)
    medium: integer                # Count of medium-priority cases (required)
    low: integer                   # Count of low-priority cases (required)
  coverage:
    functional_requirements: string  # Percentage (required, format: "N%")
    personas: string                 # Percentage (required, format: "N%")
    has_performance_tests: boolean   # Performance tests present (required)
    has_security_tests: boolean      # Security tests present (required)

Validation Rules:

• total_test_suites: Positive integer, matches test_suites array length
• total_test_cases: Positive integer, sum of all test cases across suites
• by_priority: All values non-negative; sum equals total_test_cases
• coverage.functional_requirements: Format "N%" where N is 0-100
• coverage.personas: Format "N%" where N is 0-100
• has_performance_tests: true if any test case has type: performance
• has_security_tests: true if any test case has type: security

Test Suites Array

Each test suite groups related test cases by functional area.

test_suites:
  - id: string                     # Suite identifier (required, format: ts-[slug])
    name: string                   # Human-readable suite name (required)
    description: string            # One-line scope description (required)
    requirement_refs: array<string>  # Requirement IDs this suite validates (required)
    test_cases: array<TestCase>    # Test cases for this suite (required, ≥1)

Validation Rules:

• id: Must match pattern ts-[a-z0-9-]+ (e.g., "ts-auth", "ts-workflow-loading")
• name: 5-100 characters
• description: 10-200 characters; one-line functional scope
• requirement_refs: Non-empty array of requirement IDs (e.g., ["BR-001", "TR-SEC-001"])
• test_cases: Non-empty array; at least one test case per suite

Test Case Structure

Each test case within a suite validates specific behavior.

test_cases:
  - id: string                     # Test case identifier (required, format: tc-[suite-slug]-[nnn])
    name: string                   # Plain-language test description (required)
    type: string                   # Test type (required, enum)
    priority: string               # Priority level (required, enum)
    preconditions: array<string>   # Required system state (required)
    steps: array<string>           # Numbered concrete actions (required, ≥1)
    expected_result: string        # Specific verifiable outcome (required)
    requirement_refs: array<string>  # Requirement IDs validated (required, ≥1)
    tags: array<string>            # Optional filter labels (optional)

Validation Rules:

• id: Must match pattern tc-[a-z0-9-]+-\d{3} (e.g., "tc-auth-001", "tc-wf-042")
• name: 10-150 characters; describes what is being tested
• type: Must be one of: positive, negative, edge, security, performance
• priority: Must be one of: high, medium, low
• preconditions: Non-empty array; each item 10-200 characters
• steps: Non-empty array; numbered concrete actions
• expected_result: 15-300 characters; specific and verifiable
• requirement_refs: Non-empty array; at least one requirement reference
• tags: Optional array; lowercase slugs (e.g., ["smoke", "regression", "auth"])

Test Type Definitions

Priority Definitions

---

Coverage Metrics

Functional Requirements Coverage

Calculation: (requirements_with_high_priority_tests / total_functional_requirements) * 100

Target: ≥80% functional requirements should have at least one high-priority test case.

Persona Coverage

Calculation: (personas_with_positive_test / total_personas) * 100

Target: 100% of user personas should have at least one positive test case covering their primary use case.

Non-Functional Requirements Coverage

Boolean Checks:

• has_performance_tests: true if performance targets exist in technical requirements
• has_security_tests: true if security requirements exist in technical or business requirements

---

Validation Rules Summary

Document-Level Validation

1. Version must be semantic version format 2. Generated timestamp must be valid ISO 8601 3. Both source filenames must reference existing requirement documents 4. Summary counts must match actual test case counts 5. Coverage percentages must be in range 0-100%

Suite-Level Validation

1. Suite IDs must be unique within document 2. All suites must have at least one test case 3. All requirement_refs must correspond to actual requirements 4. Suite count in summary must match test_suites array length

Test Case-Level Validation

1. Test case IDs must be unique within document 2. Test case IDs must be scoped to parent suite 3. Type must be one of five defined values 4. Priority must be one of three defined values 5. Each test case must reference at least one requirement 6. Preconditions and steps must be non-empty 7. Expected result must be specific and verifiable

Coverage Validation

1. Functional coverage calculation must be accurate 2. Persona coverage calculation must be accurate 3. NFR boolean flags must reflect actual test case presence

---

Integration with Other Documents

Inputs (Required)

• business-requirements.yaml: Provides functional requirements, user personas, success criteria
• technical-requirements.yaml: Provides API surface, security requirements, performance targets, data model constraints

Used By

• timeline.yaml: QA deadline phases reference this test plan
• milestones.yaml: Definition of done may reference test plan completion
• Developer documentation: QA teams execute test cases during delivery cycles

Relationship to Other Documents

• Test suites map to functional areas, not milestones (one-to-many)
• Test cases validate requirements, not implementation tasks (requirement-driven)
• Coverage metrics ensure all business requirements have verification path

---

Example Structure

version: "1.0.0"
project: task-automation-cli
generated: "2026-04-16T10:00:00Z"
sources:
  business_requirements: business-requirements.yaml
  technical_requirements: technical-requirements.yaml

summary:
  total_test_suites: 4
  total_test_cases: 12
  by_priority:
    high: 5
    medium: 5
    low: 2
  coverage:
    functional_requirements: "88%"
    personas: "100%"
    has_performance_tests: true
    has_security_tests: true

test_suites:
  - id: ts-authentication
    name: Authentication & Authorization
    description: Verifies user login, session management, and access control.
    requirement_refs: [BR-001, TR-SEC-001]
    test_cases:
      - id: tc-auth-001
        name: Valid credentials grant access
        type: positive
        priority: high
        preconditions:
          - User account exists with valid credentials
        steps:
          - Navigate to login page
          - Enter valid username and password
          - Click "Sign In"
        expected_result: User is authenticated and redirected to dashboard; session token is created
        requirement_refs: [BR-001]
        tags: [smoke, auth, happy-path]

See example.yaml for a complete working example.

---

Generation Process

The qa-test-plan skill follows this process:

1. Load Requirements: Read business-requirements.yaml and technical-requirements.yaml 2. Identify Test Suites: Group coverage by functional area (not milestone) 3. Generate Test Cases: Create positive, negative, edge, security, and performance cases 4. Calculate Coverage: Compute functional, persona, and NFR coverage metrics 5. Validate Output: Ensure all requirements have test coverage 6. Write File: Output to {base_directory}/delivery/qa-test-plan.yaml 7. Report Gaps: Display inline gap analysis showing uncovered requirements

---

Best Practices

Test Case Writing

• Be specific: "User sees error message 'Invalid email format'" not "Error is shown"
• Use concrete actions: "Click the Submit button" not "Submit the form"
• Make results verifiable: Include expected status codes, messages, and state changes
• Reference requirements: Every test case must trace back to at least one requirement

Coverage Strategy

• High-priority coverage: Every functional requirement and success criterion needs ≥1 high-priority test
• Persona coverage: Every user persona's primary use case needs a positive test
• NFR coverage: If technical requirements specify performance or security targets, include corresponding tests
• Edge case balance: Don't over-test edge cases; focus on realistic boundary conditions

Suite Organization

• Functional grouping: Group by feature area, not by milestone or implementation order
• Cohesive suites: Each suite should have a clear functional scope
• Requirement mapping: Suite requirement_refs should cover all test cases within the suite
• Maintainability: Keep suites focused; split large suites (>15 test cases) into smaller ones

Test Maintenance

• Update test plan when requirements change
• Mark deprecated tests rather than deleting them
• Add regression tests for fixed bugs
• Keep test case IDs stable; don't renumber when adding/removing tests