Generate Manual Test Cases from Acceptance Criteria
Generate a structured table of manual test cases covering positive, negative, edge, accessibility, and security scenarios from a user story and its acceptance criteria.
You are an experienced QA analyst. Your job is to produce a comprehensive manual test case suite from the inputs below. Before writing the test cases, list any assumptions you are making. Then output the test cases in a table. Feature name: {{FEATURE_NAME}} User story: {{USER_STORY}} Acceptance criteria (numbered list): {{ACCEPTANCE_CRITERIA}} Business rules: {{BUSINESS_RULES}} User roles involved: {{USER_ROLES}} Instructions for generating test cases: - Cover all acceptance criteria explicitly — reference the AC number in each test case. - Include at minimum: positive (happy path), negative (invalid input, boundary violations, missing required fields), edge (empty states, maximum allowed values, special characters), at least one accessibility check (keyboard navigation, visible focus, error messages announced to screen readers), and at least one security check (access by wrong role, direct URL manipulation). - Output as a Markdown table with columns: TC ID | Title | Preconditions | Steps | Expected Result | Priority (Critical/High/Medium/Low) | Type (Positive/Negative/Edge/Accessibility/Security). - Keep steps concise: each step is one action ("Enter 'x' in the email field"), not a paragraph. - After the table, add a separate "Assumptions" section listing anything you inferred that a human must validate. - Do NOT invent business rules not present in {{BUSINESS_RULES}} — if you need a rule that isn't stated, list it as an assumption. Output: 1. An "Assumptions" section. 2. The test case table in Markdown.
{{FEATURE_NAME}}requiredName of the feature being tested
e.g. Password reset via email
{{USER_STORY}}requiredThe full user story in 'As a / I want / So that' format
e.g. As a registered user, I want to reset my password via a link sent to my email, so that I can regain access to my account if I forget my password.
{{ACCEPTANCE_CRITERIA}}requiredNumbered list of acceptance criteria
e.g. 1. User enters their email and clicks 'Send reset link' 2. If the email is registered, a reset link is sent within 60 seconds 3. The reset link expires after 24 hours 4. If the email is not registered, no error is exposed (security: don't reveal account existence) 5. User can set a new password; old password no longer works
{{BUSINESS_RULES}}Additional business rules not captured in the acceptance criteria
e.g. Password must be at least 8 characters with 1 uppercase, 1 number, 1 special character. Reset links are single-use.
{{USER_ROLES}}requiredComma-separated list of user roles that can trigger this feature
e.g. registered user, admin
- Verify every acceptance criterion has at least one test case that explicitly covers it — trace AC numbers.
- Check that the negative and edge cases reflect your actual business rules, not invented ones.
- Confirm the accessibility and security test cases are appropriate for your product's risk level.
- Review the Assumptions section and resolve every open question before handing cases to testers.
- Validate that Expected Result descriptions are specific enough to pass/fail — avoid vague outcomes like 'user is shown a message'.
- Ensure test data in Steps uses synthetic values — no real email addresses, names, or passwords.
- Have a domain expert (developer or PM) sanity-check the test cases before execution.
AI output requires human review before use. These checks are your responsibility.
Example output
// NOTE: This is an illustrative partial draft. All test cases must be reviewed and enriched by a human QA analyst before use. | TC ID | Title | Preconditions | Steps | Expected Result | Priority | Type | |-------|-------|---------------|-------|-----------------|----------|------| | TC-001 | Registered user receives reset email | User account exists; user is logged out | 1. Navigate to /forgot-password 2. Enter valid registered email 3. Click 'Send reset link' | Success message shown; email received within 60s | Critical | Positive | | TC-002 | Unregistered email shows no account hint | User is logged out | 1. Navigate to /forgot-password 2. Enter email not in system 3. Click 'Send reset link' | Generic success message shown; no indication whether email is registered | Critical | Security | | TC-003 | Expired reset link is rejected | Valid reset link generated; 24 hours elapsed | 1. Open reset link after 24h | Error message: 'This link has expired' | High | Negative |
- Convert these manual test cases into Gherkin BDD scenarios using the Given/When/Then format.
- Identify which test cases in this table are strong candidates for automation and explain why.
- Generate test data for each test case, ensuring all values are synthetic and contain no real PII.
- Flag any test cases that require a specific environment setup (e.g. SMTP server, expired tokens) and suggest how to prepare them.
- The AI may invent plausible-sounding business rules not present in your actual requirements — always verify against the spec.
- Accessibility and security test cases generated by AI tend to be generic and surface-level — supplement with specialist review.
- Edge cases for complex business logic (compound validations, multi-step flows) may be missed if the business rules are not fully specified.
- Priority assignments are guesses — the AI does not know your product's actual risk profile.
- The AI may produce duplicate or nearly identical test cases that add noise without coverage value.