Writing Test Cases from User Stories & Acceptance Criteria

Writing Deeper Test Cases from Acceptance Criteria

Detailed and well thought out acceptance criteria can be a tester’s best friend. They provide a solid base for writing test cases and most importantly, they inform the team about the functionality the business is looking for.

The Purpose of Acceptance Criteria is Not to Identify Bugs

If the developer has performed their due diligence before passing over a build to QA, all bugs will have been identified and dealt with before reaching this stage. But there will of course be cases where development make last minute changes, just before passing the build over (with fingers crossed). To make sure there are no large blocking bugs, testers should always do a high level check of the acceptance criteria before moving on to begin executing their written test case.

Early Preparation

Before test cases can be written, the product owner, business, or client will need to write a detailed user story and acceptance criteria, to inform the development and testing team of how they envision the end product. Placing themselves in the mindset of the end user can be productive, enabling them to work logically through all steps the user will need the product to perform to reach a satisfactory end point. With less detailed documentation, misunderstandings can arise, with some areas potentially remaining untested. When the QA team receive the user story, a planning meeting to review all the stories will make sure all elements are fully understood. After the team meeting, testers can go ahead and write their test cases against the user story. With the software testers being involved in the planning meeting, they can contribute by helping this process to take place:

1. Business creates requirements and acceptance criteria for a user story.
2. QA reviews and begins writing test cases.
3. While examining test cases, QA identifies a scenario that is not covered by the requirements.
4. QA communicates the scenario to the Business Analyst.
5. The BA realizes a change to requirements.

If this process takes place before the development team starts or completes coding, it prevents acceptance criteria changes after the software has been delivered. Identifying requirement changes early in the process, saves the whole team a tremendous amount of time and energy.

Getting Started from Acceptance Criteria

Let’s take an example user story and add a couple pieces of acceptance criteria. Then, we’ll begin brainstorming for test cases.

Example User Story & Acceptance Criteria

As a recurring customer, I want to reorder items from my previous orders so I don’t have to search for them each time.

• AC1. Order history option is displayed on accounts page.
• AC2. Previously purchased items are displayed when clicking on order history.
• AC3. User may add previously ordered items to the cart.

Visualize the Workflow

Whether you have been testing this website (or app) for years or this is your very first time testing it, start with visualizing the workflow. What do you see when the user clicks “Order history”? What happens when they click “Add to cart”? If the user clicks the “Back” button, what is displayed? If you know the application well, you can probably quickly visualize this and get started with test case writing. If you are not as familiar with the website, you will want to observe other workflows in the application. For example, observe the behavior when clicking “Add to cart” from general search results.

Create the Happy Path

I always like to start with the happy path, a route which should encounter no errors or exceptions. It can cover a large portion of the workflow, and if it doesn’t work smoothly, the rest of your testing may be blocked. In this example, the happy path would be something like this:

1. Purchase items from general search
2. Click order history from accounts page
3. Verify that previously ordered items are displayed
4. Add items to cart from the previously ordered list
5. Complete purchase of previously ordered items

When the code is delivered to me for testing, this would be the first test case to execute.

Standard Items

Another quick and easy test case in this example, would be to verify that standard objects are displayed on the new pages. Items such as headers, footers and standard menu options can easily be missed if you don’t document them in a test case. I’ve seen links to things such as terms and conditions that are broken when a new page is added. Create test cases for verifying these standard pieces. You may have tested them so many times that you just expect them to work, and don’t consider them. A test case will save you from missing this.

Negative Testing

What are all the possible error cases that can happen? Here are some examples that come to mind with this user story:

1. Item is out of stock. They ordered it previously, but now it’s out of stock. Does this information display on the order history page?
2. Price has changed. Is this reflected on the order history page.
3. System issue occurs. What errors are displayed throughout the website when a system issue occurs? Create a test case to verify every error is displayed when it should be.

Learn more about negative testing.

Boundaries

1. How many items from order history should be displayed? If it’s not in the acceptance criteria, this needs to be addressed with the BA or product owner. The developer may code this to display all items from a customer’s history but what happens when a user has an order history of 5,000 items?
2. On the other hand, what if the user has never placed an order? Should the Order history option be displayed in the accounts page? If so, what text is displayed when the user navigates to order history?

These are examples of testing for the maximum and minimum boundaries. After asking questions like these, the product owner or BA may decide they need to create more user stories to add sorting, filtering and pagination.

Conclusion

At first glance, it might appear that acceptance criteria covers the majority of what needs to be tested. But, as you can see from this example, we generated a lot of test cases with just a bit of brainstorming. Take the time to consider the workflow, the boundaries and the negative scenarios and you will create test case coverage that far exceeds what you thought possible. Along the way you will identify requirement gaps and outstanding questions. As a result, you’ll prevent scope creep further down the road, prevent code re-work and of vital importance, save the entire team from unnecessary headaches!