speckit-spectest-plan

name	speckit-spectest-plan
description	Generate a structured test plan document from spec scenarios and success criteria
compatibility	Requires spec-kit project structure with .specify/ directory
metadata	{"author":"github-spec-kit","source":"spectest:commands/speckit.spectest.plan.md"}

Generate Test Plan

Produce a comprehensive test plan document from spec artifacts. The test plan defines what to test, how to test it, acceptance thresholds, and test environment requirements — everything a QA engineer or reviewer needs to validate the implementation.

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty). The user may specify:

• Target audience (e.g., "QA team", "developer", "stakeholder")
• Scope (e.g., "full plan", "regression only", "smoke test")
• Output location (e.g., "test-plan.md", "$FEATURE_DIR/test-plan.md")
• Specific features to include or exclude

Prerequisites

1. Confirm you are inside a git repository.
2. Resolve the active feature by running .specify/scripts/bash/check-prerequisites.sh --json from the repo root and parsing FEATURE_DIR and AVAILABLE_DOCS. The spec lives at $FEATURE_DIR/spec.md (under specs/<feature>/), not under .specify/.
3. Read spec.md completely — requirements, scenarios, success criteria, and assumptions.
4. If plan.md exists, read it for architecture context and technical decisions.
5. If tasks.md exists, read it for phase structure and dependencies.
6. Check for existing test files to understand current coverage baseline.

Outline

1. Test Plan Header: Generate document metadata.

   # Test Plan: [Feature Name from spec.md]
   
   | Field | Value |
   |-------|-------|
   | Spec | $FEATURE_DIR/spec.md |
   | Plan | $FEATURE_DIR/plan.md |
   | Date | 2026-04-10 |
   | Status | Draft |
   | Author | Generated by /speckit.spectest.plan |
   

2. Test Scope: Define what is and isn't covered.

   ## Scope
   
   ### In Scope
   - All requirements from spec.md (8 items)
   - All user scenarios (3 scenarios)
   - All success criteria (5 criteria)
   - Technical decisions from plan.md (4 decisions)
   
   ### Out of Scope
   - Performance/load testing (not specified in spec)
   - Third-party service integration testing
   - Browser compatibility (unless specified in spec)
   

3. Test Strategy: Define the testing approach by level.

   ## Test Strategy
   
   | Level | Purpose | Framework | Count |
   |-------|---------|-----------|-------|
   | Unit | Verify individual functions/methods | Jest/pytest | ~15 |
   | Integration | Verify component interactions | Supertest | ~8 |
   | E2E | Verify user workflows end-to-end | Playwright | ~4 |
   | Manual | Edge cases requiring human judgment | Checklist | ~3 |
   

4. Test Cases by Requirement: Detail test cases for each spec requirement.

   ## Test Cases
   
   ### REQ-001: User signup with email/password
   
   | ID | Test Case | Type | Priority | Expected Result |
   |----|-----------|------|----------|-----------------|
   | TC-001 | Valid email + strong password → account created | Unit | P1 | 201 Created, user in DB |
   | TC-002 | Duplicate email → rejected | Unit | P1 | 409 Conflict |
   | TC-003 | Invalid email format → validation error | Unit | P2 | 400 Bad Request |
   | TC-004 | Weak password → rejected | Unit | P2 | 400 Bad Request |
   | TC-005 | Full signup → login → access protected route | E2E | P1 | Success |
   
   **Acceptance Threshold**: All P1 tests must pass. P2 failures require documented justification.
   

5. Test Cases by Scenario: Map user scenarios to test flows.

   ### Scenario: New User Registration
   
   **Steps:**
   1. Navigate to signup page
   2. Enter valid email and password
   3. Submit form
   4. Verify confirmation email received
   5. Click verification link
   6. Verify account is active
   7. Log in with new credentials
   
   **Pass Criteria:** User can complete full flow in < 30 seconds
   **Test Type:** E2E
   **Automation:** Playwright script
   

6. Test Environment Requirements: Define what's needed to run tests.

   ## Test Environment
   
   | Component | Requirement |
   |-----------|------------|
   | Database | PostgreSQL 15+ (test instance) |
   | Runtime | Node.js 20+ |
   | Dependencies | `npm install` completes without errors |
   | Seed Data | Test fixtures in `tests/fixtures/` |
   | Environment Variables | `DATABASE_URL`, `JWT_SECRET` (test values) |
   

7. Risk Assessment: Identify testing risks from spec assumptions.

   ## Risks
   
   | Risk | Impact | Mitigation |
   |------|--------|------------|
   | External email service unavailable | E2E tests fail | Mock email service in test env |
   | Database schema changes | All tests break | Run migrations before test suite |
   | Rate limiting interferes with test speed | Flaky tests | Disable rate limiting in test env |
   

8. Output: Write the complete test plan document.

Rules

• Spec-driven — every test case must trace back to a specific requirement, scenario, or criterion in spec.md
• Prioritized — classify all test cases as P1 (must pass), P2 (should pass), or P3 (nice to have)
• Realistic — only include test cases that can actually be executed given the project's tech stack
• Complete — cover all requirements, scenarios, and success criteria from spec; explicitly mark any that are excluded and why
• Environment-aware — include realistic environment requirements based on the project's actual dependencies
• Risk-conscious — identify testing risks from spec assumptions and suggest mitigations
• Write to file — save the test plan to $FEATURE_DIR/test-plan.md by default (configurable via user input)
• Framework-specific — reference the actual test framework the project uses, not generic placeholders