test-plan-generator

Test Plan Generator

Generate detailed, structured test plans and test cases from requirements and specifications — not from code.

Important Principles

• ALWAYS work from requirements, specifications, user stories, and acceptance criteria — never from source code
• ALWAYS apply formal test design techniques systematically (see references/test-techniques.md)
• ALWAYS produce many test cases — large features need 50-150+ test cases organized hierarchically
• ALWAYS trace each test case back to a specific requirement or acceptance criterion
• NEVER skip negative testing, boundary values, or error scenarios
• NEVER produce shallow test plans with only happy-path scenarios
• Quality is more important than speed — take your time to be thorough

Workflow

Step 1: Gather Requirements

Read the ticket and all related context. Use whatever MCP tools are available:

For Jira tickets:

• Use getJiraIssue to read the main ticket
• Use searchJiraIssuesUsingJql with parent = TICKET-KEY to find subtasks
• Check for linked Confluence pages via links in the ticket or searchConfluenceUsingCql
• Read acceptance criteria, attachments descriptions, comments

For Linear tickets:

• Use get_issue to read the main ticket
• Use list_issues with project filter to find sub-issues
• Check linked documents via list_documents or get_document

For pasted text:

• Parse the requirements directly from the user's message

CRITICAL: If the ticket has subtasks or sub-issues, read ALL of them. Each subtask often contains detailed acceptance criteria that are essential for thorough test coverage.

After gathering, create a mental model of:

• What is the feature? (scope, boundaries)
• Who are the actors/users?
• What are the inputs and outputs?
• What are the business rules?
• What are the states and transitions?
• What are the integrations/dependencies?
• What are the non-functional requirements (performance, security, accessibility)?

Step 2: Analyze and Decompose

Break the feature into functional areas (test suites). For each area, identify:

1. Test conditions — what aspects need testing (ISTQB: "what to test")
2. Applicable test techniques — which formal techniques to apply (see Step 3)
3. Risk level — High/Medium/Low based on business impact and technical complexity

Consult references/test-techniques.md for detailed guidance on each technique.

Step 3: Select and Apply Test Design Techniques

For each functional area, determine which techniques apply. The skill MUST automatically select techniques based on requirement patterns:

Requirement Pattern	Technique to Apply
Input field with valid range (e.g., age 18-65)	Equivalence Partitioning + Boundary Value Analysis
Multiple conditions with different outcomes	Decision Table Testing
Workflow with distinct states (e.g., order lifecycle)	State Transition Testing
User journey / transaction flow	Use Case Testing
Multiple independent parameters (e.g., OS x Browser x Role)	Pairwise Testing
Discrete set of valid values (e.g., dropdown options)	Equivalence Partitioning
Complex business rules with exceptions	Decision Table Testing
API endpoints with request/response	Use Case Testing + EP + BVA for each parameter
Permission/role-based behavior	Decision Table (roles x actions x expected outcomes)

Apply MULTIPLE techniques per area. For example, a registration form needs: EP + BVA for each field, decision tables for validation rules, use case testing for the overall flow, and state transition for the account states.

Step 4: Generate Test Cases

For each functional area, generate test cases following this structure per test case:

**TC-{suite}-{number}: {Descriptive title}**
- **Priority:** {Critical / High / Medium / Low}
- **Technique:** {Which test design technique was used}
- **Preconditions:** {Required state before test execution}
- **Steps:**
  1. {Action step}
  2. {Action step}
  ...
- **Expected Result:** {Clear, verifiable expected outcome}
- **Requirement:** {Traceability to original requirement/AC}

Test case generation rules:

• Start with positive/happy path scenarios
• Then boundary values (on, above, below each boundary)
• Then negative scenarios (invalid inputs, unauthorized access, missing data)
• Then edge cases (empty states, max limits, concurrent operations)
• Then integration/interaction scenarios
• Then non-functional scenarios (performance, security, accessibility) if requirements mention them
• For each equivalence class — at least 1 test case
• For each boundary — test ON the boundary, BELOW, and ABOVE
• For each decision table rule — at least 1 test case
• For each state transition — at least 1 test case per valid transition + invalid transitions
• For each use case — at least 1 test for main success + 1 per extension/alternative flow

Step 5: Compile the Test Plan Document

Produce a single markdown document with this structure:

# Test Plan: {Feature Name}

## 1. Overview
- **Feature:** {name and brief description}
- **Source:** {ticket ID and link}
- **Date:** {generation date}
- **Test Approach:** {which techniques were applied and why}
- **Total Test Cases:** {count}

## 2. Scope
### In Scope
{What will be tested}
### Out of Scope
{What will NOT be tested and why}

## 3. Test Environment & Preconditions
{Required setup, test data, accounts, configurations}

## 4. Test Suites — New Capability

Test cases for the NEW functionality introduced by this feature, organized by functional area.

### 4.1 {Functional Area Name} ({count} test cases)
**Applicable techniques:** {list}
**Risk level:** {High/Medium/Low}

{All test cases for this area}

### 4.2 {Next Functional Area} ({count} test cases)
...

## 5. Test Suites — Regression

Test cases to verify that existing functionality is NOT broken by the new feature. Focus on:
- Adjacent features that share data, APIs, or UI with the new feature
- Existing workflows that the new feature modifies or extends
- Integration points where the new feature connects to existing systems

### 5.1 {Affected Existing Area} ({count} test cases)
**Why at risk:** {brief explanation of how the new feature could affect this area}

{Regression test cases}

## 6. Traceability Matrix
| Requirement/AC | Test Cases | Coverage |
|---|---|---|
| {req} | TC-XX-01, TC-XX-02 | Full / Partial |

## 7. Risks and Assumptions
{Known risks, assumptions made during test planning}

Step 6: Self-Review Checklist

Before delivering, verify:

• Every acceptance criterion has at least one test case
• Every input field has EP + BVA test cases
• Every business rule has decision table test cases
• Every workflow has state transition + use case test cases
• Negative scenarios are present for each positive scenario
• Boundary values are tested (on, below, above)
• Error handling and edge cases are covered
• Traceability matrix is complete
• Regression test cases cover existing features at risk of breaking
• Test case count is proportional to feature complexity (small feature: 15-30, medium: 30-70, large: 70-150+)

Output Format

• Output format is markdown (.md)
• Save the file to the user's workspace folder
• Use clear, consistent formatting
• Write test cases in the language of the original requirements (if requirements are in Ukrainian, write tests in Ukrainian; if in English, write in English)

Error Handling

• If the ticket cannot be read (permissions, wrong link), explain the issue and ask the user to paste the requirements text
• If requirements are vague or incomplete, note the gaps explicitly in "Risks and Assumptions" and generate test cases based on reasonable assumptions (clearly marked)
• If a subtask has no description, skip it but note it as a coverage gap

References

For detailed guidance on each test design technique with examples, consult references/test-techniques.md. For output format examples and test case templates, consult references/test-case-template.md. For quality characteristics to consider in non-functional testing, consult references/quality-characteristics.md.