Coding
Turn a feature's requirements into test cases
List test cases for a feature, covering limits, bad input, permissions and timing, and flag where the requirements don't say what should happen.
by Appndo
Tested on GPT-6.1 Sol, Claude Opus 5.5, Gemini 3.8 Flash · Verified Nov 2, 2026
The prompt
Write test cases for this feature from its requirements.
Requirements:
{{requirements}}
What else I know (platform, account types, limits, existing behaviour):
{{context}}
1. Group the cases: main path, limits and boundaries, invalid input, account types and permissions, timing (expiry, repeats, two things at once), and failures of services the feature depends on.
2. For each case give a short name, the starting state, the steps, and the expected result taken from the requirements. For every limit, test just inside, exactly at, and just outside it.
3. Where the requirements don't say what should happen, don't choose an answer: write the expected result as "Not specified" and list the question at the end.
4. Mark the cases to run first: the ones that would hurt most if they failed (security, data loss, money) and the main path.
5. End with the open questions, each naming the case it blocks.
Use only the rules I gave. Don't invent limits, messages or behaviour.How to use it
Paste the requirements as written (a ticket, a spec section, acceptance criteria) and add what a tester would need to know: account types, plan limits, platforms. Take the open questions back to whoever owns the requirements before writing automated tests.
Example
Inputs
- requirements
- Users can reset their password from the login page. They enter their email; if an account exists we send a reset link that is valid for 1 hour. A link can be used once. The new password must be 8–64 characters and must not be the same as the current password. After the reset, the user is signed in on this device and signed out everywhere else. Show the same message whether or not the email has an account.
- context
- Web app. Some accounts sign in with Google only and have no password. Reset emails are limited to 5 per hour per email address.
Output
★ Run first: main path and cases where failure could compromise accounts or session security. “Not specified” marks outcomes that require clarification.
Main path
| ID / short name | Starting state | Steps | Expected result |
|---|---|---|---|
| ★ M1 — Complete reset | Password account; current password known; reset email allowance available; active sessions on other devices. | From login, request a reset using the account email. Open the emailed link before 1 hour. Submit a different password within 8–64 characters. | Reset email arrives. Password changes. User is signed in on this device and signed out everywhere else. |
| ★ M2 — Same public message | One email has an account; another does not; neither is rate limited. | Request a reset for each email from login. Compare displayed messages. | Both show the same message. Exact wording is not specified. |
| ★ M3 — Reset another account | Two password accounts, A and B, with active sessions. | Reset A using A’s emailed link. | A’s password changes and A is signed out elsewhere. B’s password and sessions remain unchanged. |
Limits and boundaries
Use a fresh, unexpired link for each password case. Each candidate differs from the current password.
| ID / short name | Starting state | Steps | Expected result |
|---|---|---|---|
| ★ L1 — Below minimum | Password account; 7-character candidate. | Submit candidate through reset link. | Password is rejected. |
| ★ L2 — At minimum | Password account; 8-character candidate. | Submit candidate through reset link. | Password is accepted; reset and required session changes complete. |
| L3 — Inside minimum | Password account; 9-character candidate. | Submit candidate through reset link. | Password is accepted; reset and required session changes complete. |
| L4 — Inside maximum | Password account; 63-character candidate. | Submit candidate through reset link. | Password is accepted; reset and required session changes complete. |
| ★ L5 — At maximum | Password account; 64-character candidate. | Submit candidate through reset link. | Password is accepted; reset and required session changes complete. |
| ★ L6 — Above maximum | Password account; 65-character candidate. | Submit candidate through reset link. | Password is rejected. |
| L7 — Inside email allowance | Existing password account; 3 reset emails sent within the applicable hour. | Request a fourth reset email. | A fourth reset email is sent. |
| L8 — At email allowance | Existing password account; 4 reset emails sent within the applicable hour. | Request a fifth reset email. | A fifth reset email is sent. |
| ★ L9 — Above email allowance | Existing password account; 5 reset emails sent within the applicable hour. | Request a sixth reset email. | No sixth reset email is sent within that hour. Displayed response is Not specified. |
The meaning of “character” and the definition of the hourly window need clarification; see Q1 and Q2.
Invalid input
| ID / short name | Starting state | Steps | Expected result |
|---|---|---|---|
| I1 — Empty email | Login page. | Submit an empty email field. | Not specified. |
| I2 — Malformed email | Login page. | Submit text that is not an email address. | Not specified. |
| ★ I3 — Current password reused | Password account; valid unused link. | Submit the current password as the new password. | Password is rejected. |
| I4 — Empty password | Password account; valid unused link. | Submit an empty new password. | Password is rejected because it is below 8 characters. |
| ★ I5 — Missing or altered token | Reset URL with its token removed or changed. | Open the URL and attempt a password reset. | Not specified. |
| I6 — Email formatting | Existing account email. | Request resets using case changes or surrounding spaces in the email address. | Not specified. |
Account types and permissions
| ID / short name | Starting state | Steps | Expected result |
|---|---|---|---|
| ★ A1 — Google-only account | Account signs in with Google only and has no password. | Request a reset, then follow any available reset flow. | Not specified whether this creates a password, sends a link, or permits reset. Public message must match the message for an email without an account. |
| A2 — Unknown email delivery | Email has no account. | Request a reset. | Public message matches the message for an existing account. Whether any email is sent is Not specified. |
| ★ A3 — Different signed-in account | Browser is signed in as B; a valid reset link belongs to A. | Open A’s link and complete reset. | A’s password changes; A is signed in on this device and signed out elsewhere. Treatment of B’s existing browser session is Not specified. |
Timing: expiry, repeats, and concurrency
Use a different, valid-length password for successful reset attempts. Expiry tests require a defined start time and time precision; see Q6.
| ID / short name | Starting state | Steps | Expected result |
|---|---|---|---|
| ★ T1 — Just before expiry | Unused link, immediately before its 1-hour expiry. | Complete reset before expiry. | Reset succeeds, with required session changes. |
| ★ T2 — Exactly at expiry | Unused link, exactly at the 1-hour boundary. | Submit reset. | Not specified whether the exact boundary is inclusive or exclusive. |
| ★ T3 — Just after expiry | Unused link, immediately after its 1-hour expiry. | Attempt reset. | Link is expired and cannot reset the password. |
| ★ T4 — Link reused | Link has successfully reset the password once. | Use it to attempt another reset. | It cannot reset the password again. |
| T5 — Open link repeatedly | Valid unused link. | Open it twice before submitting a new password. | Not specified whether opening counts as use. |
| T6 — Retry after rejection | Valid unused link; an invalid password was rejected. | Retry with a different, valid-length password. | Not specified whether the rejected attempt consumed the link. |
| T7 — Multiple issued links | Two reset links issued for the same account, within the allowance. | Attempt reset using each link. | Not specified whether issuing or using one invalidates the other. |
| ★ T8 — Same link, simultaneous resets | One valid unused link open in two clients. | Submit two different valid passwords simultaneously. | At most one reset succeeds, because a link can be used once. Which request wins is Not specified. |
| ★ T9 — Concurrent email requests at cap | 4 reset emails already sent in the applicable hour. | Submit two reset requests simultaneously. | At most one additional reset email is sent; total does not exceed 5. Which request receives it and the responses are Not specified. |
| T10 — Hourly allowance renewal | Email has reached its hourly allowance. | Request immediately before, exactly at, and immediately after the allowance-renewal boundary. | Not specified until the hourly window and boundary rules are defined. |
| ★ T11 — Submission crosses expiry | Link is valid when opened or submitted, but expires before processing completes. | Complete a reset across the expiry boundary. | Not specified when validity is checked. |
| ★ T12 — Session created during reset | Account has a valid reset in progress. | Sign in elsewhere while completing the reset. | Not specified how concurrent session creation is ordered against signing out everywhere else. |
Failures of dependent services
These cases apply to whichever components provide the named function; they do not assume a particular architecture.
| ID / short name | Starting state | Steps | Expected result |
|---|---|---|---|
| F1 — Email delivery failure | Existing password account; allowance available; email delivery fails or times out. | Request a reset. | Not specified: response, retries, allowance consumption, and link validity. |
| F2 — Account lookup failure | Account lookup is unavailable. | Request a reset. | Not specified: response and recovery. |
| ★ F3 — Link storage failure | Reset-link creation or storage fails. | Request a reset. | Not specified: response, email sending, and recovery. |
| ★ F4 — Password save failure | Valid unused link; password storage fails. | Submit a valid new password, then retry after recovery. | Not specified: final password, link consumption, session changes, and retry behavior. |
| ★ F5 — Sign-in failure | Password save succeeds; signing in this device fails. | Complete reset. | Not specified: rollback, user response, and recovery. |
| ★ F6 — Sign-out failure | Password save succeeds; signing out other sessions fails. | Complete reset. | Not specified: completion status, retries, rollback, and user response. |
| ★ F7 — Response lost | Server processes a reset, but the browser loses the response. | Resubmit using the same link. | If the first reset completed, the link cannot reset again. Displayed result and recovery are Not specified. |
| ★ F8 — Rate-limit service failure | Email allowance cannot be checked or updated. | Request a reset email. | Not specified: whether requests are accepted, rejected, or retried. |
Open questions
- Q1 — Character counting: What counts as a character for Unicode passwords? Are spaces preserved or trimmed? Blocks Unicode and whitespace variants of L1–L6.
- Q2 — Hourly window: Is the email limit rolling or fixed? What are its exact renewal boundary and time precision? Blocks T10 and precise setup of L7–L9, T9.
- Q3 — Rate-limit response: What should the user see at the cap, and must that response also be identical for existing and nonexistent accounts? Blocks the response assertions in L9, T9.
- Q4 — Email validation: How should empty, malformed, case-varied, and whitespace-padded emails be handled? Blocks I1, I2, I6.
- Q5 — Invalid tokens: What must happen for missing, altered, or unrecognized reset tokens? Blocks I5.
- Q6 — Expiry semantics: When does the hour start, what time precision applies, is the exact boundary valid, and when is expiry checked? Blocks precise execution of T1–T3 and the expected results for T2, T11.
- Q7 — Link consumption: Does opening a link or submitting a rejected password consume it? Blocks T5, T6.
- Q8 — Multiple links: Does issuing or using a new link invalidate earlier links? Blocks T7.
- Q9 — Google-only accounts: Can reset establish a password, and should a reset email be sent? Blocks A1.
- Q10 — Unknown email delivery: Is any email sent for an address without an account? Blocks the delivery assertion in A2.
- Q11 — Existing browser identity: What happens to B’s session when A completes a reset in B’s browser? Blocks that assertion in A3.
- Q12 — Concurrent sessions: How are sign-ins occurring during reset handled by “signed out everywhere else”? Blocks T12.
- Q13 — Request-service failures: What responses, retries, and allowance effects apply when email delivery, account lookup, link storage, or rate-limit services fail? Blocks F1–F3, F8.
- Q14 — Partial reset failures: What are the required password, token, and session states when password saving, current-device sign-in, or other-device sign-out fails? How does recovery work? Blocks F4–F6.
- Q15 — Lost response: What should the browser display and how should the user recover after a completed reset’s response is lost? Blocks the recovery assertions in F7.
One real run with the example above. Results vary between runs and models.