How are test cases derived from a user story?
A user story ("as a customer I can pay with a saved card so that checkout is faster") becomes testable through its acceptance criteria: each criterion, written as a precondition, an action and an observable result, maps to at least one test case, and the questions the story does not answer — a declined card, an expired one, no saved card at all — become the negative cases. The story's benefit clause ("so that") says what to measure; the role says which permissions to test with. A story with no acceptance criteria is not ready for testing, and usually not for development either.
Read the guide: How to Write Test Cases
How to use AI Requirement → Test Scenarios
- Paste the requirements or specification — a PRD section, user stories or numbered rules.
- Choose how many scenarios you want (3 to 30) and the output language.
- Press Generate: main flows come first, then alternate, exception, cross-feature and non-functional scenarios.
- Read the coverage notes to see which requirements are covered and which cannot be tested end to end, then download as CSV, Markdown or JSON.
AI Requirement → Test Scenarios features
- Main, alternate, exception, cross-feature and non-functional scenario kinds
- Preconditions, flow steps and expected outcome per scenario
- Coverage notes highlighting what is and is not covered
- Markdown, CSV and JSON export
AI Requirement → Test Scenarios example
Spec → scenarios
Input:
Password reset by 6-digit email code valid for 10 minutes, max 5 attempts…Output:
TS-01 (main) Successful reset with a valid code
TS-02 (exception) Code expired after 10 minutes
TS-03 (exception) Sixth attempt is rejected
…Frequently asked questions about AI Requirement → Test Scenarios
What is the difference between a scenario and a test case?
A scenario is an end-to-end flow (main, alternate, exception, cross-feature or non-functional) that can be expanded into several detailed test cases. Use the Requirement → Test Cases tool for the detailed level.
Why are the flow steps not click-by-click?
Scenarios describe business actions — "the customer requests a reset code", not "click the button" — so they stay valid when the UI changes and can be agreed with product owners. Expand a scenario into click-level cases with Requirement → Test Cases.
What goes in the coverage notes?
Which requirements each scenario covers, and which requirements cannot be tested end to end — for example an internal rule with no observable effect — so the gaps are visible before test design starts.
Technical notes
Each scenario has an ID (TS-01, TS-02 …), a kind (main, alternate, exception, cross-feature or non-functional), a P0–P3 priority, a description of what it exercises and why it matters, preconditions, three to ten business-level flow steps, the expected outcome and the requirement numbers it traces to.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)The agile testing quadrants and how testers work inside a delivery team — the basis of "testing at the right layer".
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.