One of the most common responsibilities in software testing is translating user stories and acceptance criteria into well-structured test cases. While this may appear straightforward, doing it effectively requires a systematic approach and attention to detail.

Test cases derived directly from requirements ensure full coverage, improve traceability, and significantly reduce the risk of missing critical scenarios.

This guide provides a clear and structured approach to creating test cases from user stories and acceptance criteria.

Step 1: Analyze the User Story and Acceptance Criteria

Before writing any test case, carefully review and fully understand the user story and its acceptance criteria. Each acceptance criterion represents a functional requirement that must be validated.

Example User Story

As a user, I want to reset my password if I forget it.

Acceptance Criteria

-“Forgot Password” link is visible on the login screen.

-OTP is sent to the registered email address.

-OTP expires after 5 minutes.

-New password must meet security requirements: minimum 8 characters, at least one number, and one symbol.

At this stage, the goal is to identify what must be tested. Each acceptance criterion should translate into at least one positive test case.

Step 2: Write Positive Test Cases

Positive test cases verify that the system behaves as expected under normal and valid conditions. These are derived directly from the acceptance criteria.

From the example above:

-Verify that the “Forgot Password” link appears on the login screen.

-Verify that an OTP is sent within 2 minutes of requesting a password reset.

-Verify that the OTP cannot be used after 5 minutes.

-Verify that a password meeting all security requirements is accepted.

Each test case should clearly define:

-Preconditions

-Test data

-Steps

-Expected results

Clarity ensures that any team member can execute the test without ambiguity.

Step 3: Identify Negative Test Cases

Negative testing ensures the system handles invalid inputs and unexpected user behavior gracefully. These scenarios may not always be explicitly stated in the acceptance criteria, but they are critical for robust testing.

Key questions to consider:

-What happens when an unregistered email address is entered?

-What happens when an incorrect OTP is submitted?

-What happens if the user attempts to reuse an expired OTP?

-What happens when a weak password is entered?

Capturing these scenarios helps prevent defects from reaching production and strengthens overall system reliability.

Step 4: Test Boundaries and Edge Cases

Boundary testing focuses on limits and extreme conditions. If acceptance criteria do not specify boundaries, this may reveal a requirement gap that should be clarified with the product owner.

Examples:

-How many OTP requests can be made within an hour?

-Is there a lockout mechanism after multiple failed attempts?

-What happens if the email service is temporarily unavailable?

-What happens when a user with no prior orders accesses order history?

Identifying edge cases early improves both requirement quality and overall test coverage.

Step 5: Use a Consistent Test Case Format

A standardized test case format enhances readability, maintainability, and execution efficiency across the team.

Conclusion

Writing test cases from user stories and acceptance criteria is a foundational skill in software testing. By systematically analyzing requirements, incorporating positive, negative, and boundary scenarios, and maintaining a consistent structure, testers can ensure comprehensive coverage and improved software quality.