1. Write more in-depth test cases from an acceptance criteria

Detailed and understandable acceptance criteria can be a tester’s best friend. They provide a basis for writing test cases and most importantly they inform the team of the functionality the business is looking for.

1.1. The purpose of acceptance criteria is not to identify errors

If the developer has done their function before sending the build to QA, all bugs will be identified and resolved before reaching this stage. But of course there will be cases where a last-minute change is needed, right before submitting the build. To ensure there are no major errors, the tester should always carefully test the acceptance criteria before moving on to start running their test case.

1.2. Prepare early

Before test cases can be written, the product owner, business or customer will need to write detailed user stories and acceptance criteria, to notify the developers and testers about how they visualize the final product. Putting yourself in the mind of an end-user can be highly effective, allowing them to work logically through all the steps the user will need to get the product to its destination. With less detailed documentation, misunderstandings can arise, leading to a number of potentially untested points. When the QA team receives the user story, a meeting is scheduled to review all user stories to ensure all functions are fully understood. After the team meeting, the tester can continue writing their test case with the user story. With testers participating in a planning meeting, they can collaborate by helping address the following points:

1. The business team creates requirements and acceptance criteria for a user story.
2. QA reviewed and started writing test cases.
3. While testing test cases, QA determines that the scenerio is not covered in the requirements.
4. QA communicates scenerio to Business Analyst.
5. BA recognizes a change according to the requirement.

If this process takes place before the team develops or completes the code, it will prevent the acceptance criteria changes after the software is released. Identify requirements changes early in the process, saving the whole team a great deal of time and effort.

1.3. Starting from accept criteria

Take a sample user story and add some acceptance criteria. After that, we will start thinking to write test cases.

1.3.1. Examples of acceptance criteria and user story

1.4. Visualize the workflow

Whether you’ve been testing the web (or app) for years or it’s the first time you’ve tested this site, start by visualizing the workflow. What do you see when a user clicks on “Order history”? What happens when they click “Add to cart”? If the user clicks the Back button, what is displayed? If you know this application well, maybe you can quickly figure this out and start writing test cases. If you are not familiar with the website, you will want to observe other workflows in the application. For example, observe behavior when clicking “Add to cart” from the general search results.

1.4.1. Create the Happy Path

I have always liked to start with a happy path, which has no errors or exceptions. It may include a large set of steps to perform and if it does not work smoothly, the rest of your work may be blocked. In this example, the happy path will look like this:

1. Buy items from general search
2. Click “Order history” from the account page
3. Verify that the previously ordered items are displayed
4. Add items to the cart from the previous order list
5. Complete the purchase of previously ordered items

When the build is sent to me for testing, this will be the first test case to be executed.

1.4.2. Standard Items

Another quick and easy test case in this example, would be to verify that standard objects are displayed on pages. Items like headers, footers and standard menus can easily be ignored if you didn’t rewrite them in test cases. I have seen links to things like terms and conditions fail when adding a new page. Create test cases to verify standard items. You may have tested them so many times that you just expect them to work and not consider them. A test case will save you from missing this.

1.4.3. Negative Testing

What are all possible error cases? Here are some examples that appear in this user story:

1. Sold out already. They had placed an order before, but now are out of stock. Does this information show up on order history page?
2. Price has changed. This is reflected on the order history page.
3. System problem occurred. What errors are displayed on the entire site when a system problem occurs? Create a test case to verify every error is displayed when needed.

1.4.4. Boundaries

1. How many items from the order history will be displayed? If it is not in the acceptance criteria, this needs to be resolved with the BA or the product owner. Developers can code this place to display all items from the 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 account page? If so, what text is displayed when the user navigates to “Order history”?

These are examples of testing the maximum and minimum marginal values. After asking such a question, the product owner or BA may decide they need to create additional user stories to add sorting, filtering and paging.

2. Conclusion

At first glance, it seems that acceptance criteria cover most of what needs to be tested. But, as you can see from this example, we have created a lot of test cases with just a little thought. Take the time to review the workflow, marginal values ​​and negative cases, and you will create test cases for each case far beyond what you might think. Accordingly, you will identify the requirement and ask questions. Therefore, you will prevent the lack of requirements, prevent the develop again from the beginning and have a vital importance, saving the entire team from unnecessary mistakes!

3. Reference

• Writing Test Cases from User Stories & Acceptance Criteria