Test planner

​

Purpose

• Generate comprehensive test strategies from specifications
• Create test matrices with input combinations and boundary values
• Define test coverage targets per implementation phase (FASE)
• Create performance test scenarios from NFRs
• Audit test coverage of existing specs

​

When to use

• Specifications exist in spec/ and have been audited by spec-auditor
• You need a test strategy before generating implementation plans
• You want to define test coverage targets per FASE
• You need performance test scenarios derived from NFRs
• You want to audit test completeness of existing BDD specs
• You want to generate test matrices for complex use cases

​

Modes of operation

​

Generate test strategy

• Use cases without BDD files
• Use cases with BDD but missing exception flows
• Invariants without property tests
• NFRs without measurable test scenarios

​

Generate test matrices

• Equivalence partitioning: For each input, identify valid and invalid partitions
• Boundary value analysis: For numeric/range inputs, identify boundary values (min-1, min, min+1, max-1, max, max+1)
• Decision table: For use cases with multiple conditions, build condition/action table
• State transition: For entities with state machines, generate tests for each valid and invalid transition

​

Generate performance scenarios

​

Audit test coverage

​

Workflow

​

What this stage produces

• Test plan at test/TEST-PLAN.md with:
  • Test strategy summary with coverage targets
  • Test levels (unit, integration, E2E, performance, security) with techniques and frameworks
  • Test gaps identified with priority levels
  • Per-FASE test targets mapping test types to implementation phases
  • Regression strategy (when to run which tests)
• Test matrices at test/TEST-MATRIX-UC-{NNN}.md with:
  • Inputs with valid/invalid partitions and boundary values
  • Decision tables mapping conditions to expected actions
  • State transition tests for stateful entities
  • Traceability to use case sections
• Performance scenarios at test/PERF-SCENARIOS.md with:
  • Targets from NFRs (response time, throughput, concurrent users, rate limits)
  • Scenarios (smoke, load, stress, soak, spike) with success criteria

​

Key principles

​

Test independence

​

Traceability

​

Risk-based prioritization

1. Business criticality of the use case
2. Failure impact (data loss > UX issue)
3. Probability of defect (complex logic > simple CRUD)

​

Shift-left testing

​

Real example

# Test Matrix: UC-001 — Authenticate user

## Inputs

| Input | Type | Valid Partitions | Invalid Partitions | Boundaries |
|-------|------|------------------|--------------------|------------|
| email | string | Valid email format ([email protected]) | Missing @, invalid domain, empty | N/A |
| password | string | 8-64 chars with mixed case + digit + special | < 8 chars, > 64 chars, missing requirements | 7, 8, 9, 63, 64, 65 chars |

## Decision Table

| # | Email valid | Password valid | Account status | Expected Action | Expected Status |
|---|-------------|----------------|----------------|-----------------|------------------|
| T1 | true | true | active | Generate JWT token | 200 |
| T2 | true | true | locked | Return error message | 403 |
| T3 | true | false | active | Return invalid credentials | 401 |
| T4 | false | true | active | Return invalid email format | 400 |
| T5 | false | false | active | Return invalid email format | 400 |

## Traceability

| Test Case | Covers | Spec Ref |
|-----------|--------|----------|
| T1 | Main flow | UC-001 §main |
| T2 | Exception flow: account locked | UC-001 §exception.3 |
| T3 | Exception flow: invalid credentials | UC-001 §exception.2 |
| T4 | Exception flow: invalid email | UC-001 §exception.1 |

​

Pipeline integration

spec-auditor → audits/AUDIT-BASELINE.md
        ↓
test-planner → test/TEST-PLAN.md, test/TEST-MATRIX-*.md (THIS SKILL)
        ↓
plan-architect → plan/