Generate Test Cases from Requirements with AI
Given one requirement, the model returns a structured suite of 8-10 test cases — ID, title, preconditions, steps, expected result, priority, and the design technique that generated each case — covering happy path, negative scenarios, boundary values, equivalence partitions, and edge cases.
When to use it
- You have a written requirement or acceptance criterion and need a first-pass test suite.
- You want consistent coverage of negative and boundary scenarios that humans tend to skip.
- You're onboarding a new tester and need a reference for ISTQB-style technique application.
- You're auditing existing test coverage against a requirement to find gaps.
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a senior test designer with ISTQB Advanced certification. You apply equivalence partitioning, boundary value analysis, and edge case identification with discipline.
</role>
<context>
The team writes test cases in a structured Markdown table format. Every test case must cite the design technique that produced it so reviewers can verify coverage. Cases are prioritized P1 (must), P2 (should), P3 (could).
</context>
<task>
From the requirement I provide, generate 8-10 test cases covering:
- Happy path (positive scenarios)
- Negative scenarios (invalid inputs, unauthorized access, etc.)
- Boundary values (just inside / on / just outside each numeric or length boundary)
- Equivalence partitions (one case per valid and invalid class)
- Edge cases (Unicode, null, empty, max length, simultaneity)
At least 30% of cases must be non-happy-path.
</task>
<input>
Requirement: {requirement}
Additional constraints (optional): {constraints}
</input>
<constraints>
- 8-10 cases, no more, no less.
- Each case has columns: ID, Title, Preconditions, Steps, Expected Result, Priority (P1/P2/P3), Technique (EP / BVA / Edge / Negative / Happy).
- Steps numbered 1, 2, 3 — no narrative.
- Expected Result is observable and atomic — no "system behaves correctly".
- Do not invent fields not present in the requirement.
</constraints>
<output_format>
A Markdown table with the 7 columns above, followed by a 2-3 sentence "Coverage notes" paragraph explaining which equivalence classes were covered and which weren't (and why).
</output_format>
Think through the equivalence classes and boundaries before writing the table.Example
Common pitfalls
- Model defaults to mostly happy-path cases; the 30% non-happy-path constraint is essential.
- Boundary values often come out as 'representative' rather than literal on/just-outside boundaries — review explicitly.
- Without the technique column, you can't tell whether coverage is broad or shallow.
- Model may invent fields (e.g., 'username') not present in the requirement — keep the don't-invent constraint.
Tips
- Paste the requirement verbatim, not your summary of it — phrasing matters for what constraints the model picks up.
- If the requirement has 4+ fields, ask for 12-15 cases instead of 8-10 to keep boundary coverage complete.
- Pair this prompt with `boundary-equivalence-generator` when the requirement has many numeric fields — that prompt goes deeper on BVA.
- For acceptance criteria from a story, run `create-bdd-scenarios` instead — Gherkin output is closer to the user's domain language.
FAQ
This prompt produces test cases in a tabular ISTQB-style format optimized for test management tools (Zephyr, TestRail, qTest). BDD scenarios are written in Gherkin and live next to step definitions in a code repo. Use this for test-management workflows; use BDD when tests live in code.
Related prompts
Create BDD Scenarios in Gherkin
Reads a user story and returns Cucumber-compatible Gherkin scenarios covering happy path, error scenarios, and at least two edge cases. Uses Scenario Outline with Examples tables when 2+ data variations exist. Forbids UI implementation detail in Then steps.
Open →Boundary Value & Equivalence Partition Generator
Reads field constraints (min/max/length/format) and returns boundary and equivalence-partition cases for each — values just inside, on, and just outside the boundary — with technique labels (BVA or EP) per case.
Open →Generate Test Data Fixtures from Schema
Reads a data schema (JSON Schema, TypeScript type, or table description) and returns four explicit fixture groups — happy path, boundary, invalid, and edge cases. Edge group must include Unicode, RTL, emoji, and injection payloads. Output is a ready-to-import JSON file.
Open →Risk-Based Testing Prioritization
Reads a feature list and outputs a prioritization matrix with four weighted dimensions (business impact, technical complexity, usage frequency, defect history) scored 1-5, total weighted score, recommended test execution order, and tie-break rule.
Open →