User Story → Acceptance Criteria → Test Cases Flashcards
What is Acceptance criteria
acceptance criteria is key for both testers and developers.
🔍 What is Acceptance Criteria?
Acceptance Criteria (AC) are specific conditions that a user story must meet to be considered complete and accepted by the product owner or stakeholder.
Think of it as a checklist of what the software must do for that user story to be marked “done.”
🧠 In simple terms:
> “It’s the definition of done for a user story.”
🧾 Example:
User Story:
> “As a user, I want to be able to reset my password using my email so that I can regain access to my account.”
Acceptance Criteria:
1. User must enter a valid registered email address.
2. A reset link is sent to the email.
3. The reset link expires after 15 minutes.
4. User is able to set a new password through the link.
5. Confirmation message is shown after successful reset.
✅ Why It’s Important for a Tester:
- You use AC to create your test cases.
- It helps you understand what needs to be tested.
- It keeps your testing within scope.
- It sets clear expectations for the whole team.
What is a Test Case?
A test case is a step-by-step document that describes how to verify a specific function or feature of the software — based on requirements or acceptance criteria.
> It tells you what to test, how to test it, what to expect, and what the actual result is.
🧾 A Simple Test Case Format:
|——————|——-|
| Steps |
1. Go to login page
2. Click “Forgot Password”
3. Enter a valid registered email
4. Click “Submit” |
| Expected Result | A password reset email is sent to the provided email |
| Actual Result | (You fill this in after testing) |
| Status | Pass / Fail |
| Notes | (Optional – screenshots, error messages, etc.) |
🛠 Why Test Cases Matter:
- Make sure the system works as expected
- Help reproduce bugs
- Ensure complete test coverage
- Useful for regression testing
- Can be shared with team members or auditors
🧠 Quick Tip:
> Every acceptance criterion from the user story can turn into one or more test cases.
| Title | Verify password reset with a valid email |
| Precondition | User must have a registered account |
Test Case ID | TC001 |
🔁 Relationship between User Story, Acceptance Criteria, and Test Case:
- ✅ User Story
→ Tells what the user wants and why. - ✅ Acceptance Criteria (AC)
→ Lists the conditions that must be true for the user story to be considered complete. - ✅ Test Cases
→ Are derived from the acceptance criteria to verify that the system behaves correctly.
🔄 Flow:
> User Story → Acceptance Criteria → Test Cases
🔍 Example:
User Story
> “As a user, I want to reset my password via email so I can regain access to my account.”
Acceptance Criteria
1. User enters a valid registered email.
2. System sends a reset link to the email.
3. Link expires in 15 minutes.
4. User can set a new password via the link.
5. Confirmation message is shown.
Test Cases Derived from AC:
| Test Case ID | Title | Steps | Expected Result |
|————–|——-|——-|—————–|
| TC001 | Reset with valid email | Enter registered email & submit | Email with reset link is received |
| TC002 | Reset with invalid email | Enter unregistered email & submit | Error message displayed |
| TC003 | Link expiration | Wait 15+ mins and click link | Link shows expired message |
| TC004 | Successful password change | Open link, enter new password | Success message is shown, password updated |
So to answer your original thought:
> ❓ “User story from acceptance criteria?”
➡️ It’s actually the other way around:
> ✅ Acceptance Criteria come from the User Story, and Test Cases come from the Acceptance Criteria.
Want me to give you a practice exercise with a fake user story so you can try writing AC and test cases?
“Every acceptance criterion from the user story can turn into one or more test cases”
It means that for each acceptance criterion (AC), you can write at least one test case, sometimes multiple — depending on how many ways you need to test that condition.
🧠 Think of it like this:
- Acceptance Criteria = What the software must do
- Test Case(s) = How you’ll test that it actually does it
🔍 Example:
✅ Acceptance Criterion:
> “The password reset link must expire after 15 minutes.”
You might create multiple test cases from just this one AC:
So even though it’s one acceptance criterion, you want to test it from different angles — before expiry, after expiry, and trying to use it again.
💡 Summary:
- One acceptance criterion = Minimum one test case
- But depending on the situation = May need multiple test cases to cover different scenarios, edge cases, and negative tests
Test Case ID | Test Description |
|————–|——————|
| TC001 | Verify the link works before 15 minutes |
| TC002 | Verify the link shows “expired” after 15 minutes |
| TC003 | Verify expired link does not allow password reset |
Test case example
🔧 Acceptance Criterion for Practice:
User must receive an error message when trying to log in with an incorrect password.
🔧Test case for Practice:
| Test Case ID | (e.g., TC001) |
| — | — |
| Title | Verify error message when trying to log in with an incorrect password. |
| Precondition | User must have a registered account with a known valid email and password |
| Steps | 1. Go to login page 2. Enter valid registered email address
3. Enter incorrect password
|
| Expected Result | Click the “Login” button |
A clear error message such as “Incorrect password. Please try again.” is displayed, and the user is not logged in | |
who writes what
who writes what really helps you understand how teams work together in Agile. 👇
👥 Who Writes the User Story?
Usually written by:
- Product Owner (PO)
- Sometimes in collaboration with:
- Business Analysts
- Developers
- Testers (you!)
The Product Owner is responsible for understanding business needs and turning them into user stories that describe what the user wants and why.
🧾 Who Writes the Acceptance Criteria (AC)?
Usually written by:
- Product Owner
- Often with input from:
- QA/Testers ✅
- Developers ✅
- UX Designers (if it involves UI)
The AC defines how we know the story is complete, so the team often helps write or refine them — especially QA, because we think in terms of “how to test this.”
🤝 Best Practice:
Cross-functional teams collaborate on refining user stories and ACs during:
- Backlog refinement
- Sprint planning
- Three Amigos meetings (PO + Dev + QA)
🔑 Quick Summary:
Item | Who Writes It |
|——|—————-|
| User Story | Product Owner (with team input) |
| Acceptance Criteria | Product Owner + QA + Dev (collaboratively) |
| Test Cases | QA/Testers |
