AI in Software Testing
How to Generate Test Cases from a User Story Using AI
Learn how to transform user stories and acceptance criteria into structured positive, negative, validation and boundary test cases.
Introduction
A user story explains a user goal. Test cases explain how to verify that goal. AI can accelerate the first draft when the story, acceptance criteria and constraints are explicit—and when a tester reviews the output before release validation.
What makes a good user story?
A useful story states the role, goal and value, then adds acceptance criteria that are observable. Prefer measurable rules over vague phrases such as “works correctly” or “is secure.”
Information required before generating test cases
- User role and permission level
- Acceptance criteria and business rules
- Validation limits and error messages
- Dependencies such as email, MFA or account status
- Synthetic test data examples
Example user story
As a registered customer,
I want to sign in using my email address and password
so that I can access my account.Example acceptance criteria
- The email and password fields are required.
- A valid registered user can sign in.
- Invalid credentials show a generic error message.
- The account is temporarily locked after five failed attempts.
- Password characters are masked.
- The user can select Remember Me.
How to identify positive scenarios
Start with the successful path: a registered active user enters valid credentials and reaches the documented destination. Then add valuable variations such as Remember Me enabled or keyboard-only submission.
How to identify negative scenarios
Cover invalid credentials, missing required fields, locked accounts and other disallowed states. Confirm that no authenticated session is created and that error messages remain useful without revealing unnecessary account details.
How to identify boundary conditions
Look for numeric or length limits, attempt counters and timing rules. For this story, five failed attempts is an explicit boundary: attempt four may still allow a later success, while attempt five should lock the account according to the acceptance criteria.
How to identify missing requirements
Ask what the story does not say. Examples include password reset, MFA, inactive accounts, session timeout and social login. Capture these as open questions instead of inventing unsupported rules in the test suite.
Example test-case table
| Test case ID | Scenario | Preconditions | Test steps | Test data | Expected result | Priority | Type |
|---|---|---|---|---|---|---|---|
| US-01 | Valid registered user signs in | Active registered account exists | Open login, enter valid email and password, submit | registered.user@example.test / ValidPass1! | User is authenticated and reaches the account destination | High | Positive |
| US-02 | Missing password is rejected | Login page is available | Enter email only and submit | registered.user@example.test / (blank) | Submission is blocked and a required-field message is shown | High | Validation |
| US-03 | Invalid credentials show a generic error | Active registered account exists | Enter valid email with incorrect password and submit | registered.user@example.test / WrongPass1! | Access is denied with a generic error; no session is created | High | Negative |
| US-04 | Account locks after five failed attempts | Active account with zero failed attempts | Submit incorrect password five times | Five invalid password attempts | Account becomes temporarily locked according to policy | High | Boundary |
| US-05 | Password characters are masked | Login page is available | Enter a password and observe the field | Any password value | Characters are masked by default | Medium | Positive |
| US-06 | Remember Me can be selected | Login page is available | Select Remember Me, sign in with valid credentials | Valid credentials + Remember Me checked | Remember Me selection is accepted and behaviour matches the documented policy | Medium | Positive |
Common mistakes
- Providing only the one-line story and expecting complete coverage
- Keeping AI assumptions that are not in the acceptance criteria
- Using real credentials or customer data in examples
- Automating the draft before expected behaviour is confirmed
Review checklist
- Every case maps to a criterion or identified risk
- Expected results are observable
- Negative cases verify that state does not change incorrectly
- Open questions are listed separately from confirmed requirements
How AutomationTekAI can help
Paste the story and acceptance criteria into the Generate workflow, or use a supported Jira issue key when configured. Treat the result as a draft, then export it into your normal QA process.
Key takeaways
- Clear acceptance criteria produce better AI drafts.
- Positive, negative, validation and boundary cases belong together.
- Human review remains mandatory before release validation.
Frequently asked questions
Can AI create complete coverage from one user story?
No. AI can produce a useful first draft, but coverage still depends on requirement quality, product context, integrations and professional QA review.
Should I include acceptance criteria in the prompt?
Yes. Include roles, acceptance criteria, validations, limits, permissions and expected errors so the draft stays grounded in explicit behaviour.
Can I start from a Jira story?
Yes. AutomationTekAI can fetch supported Jira issue keys when credentials are configured, or you can paste the story and acceptance criteria into the text workflow.