How to Write Test Cases From User Stories

How to write test cases for both manual and automated tests

Immerse yourself in the basics -- and particulars -- of writing test cases for both manual and automated tests, and learn the components crucial to each approach.

One of the most important responsibilities for testers is writing test cases. Different organizations have varying standards for how to write test cases, largely because development teams use test cases in all types of software across virtually all industries. On a similar note, teams use test cases in a variety of different organizational methodologies, including Agile, DevOps or any other software development approach. When you take all these variables into consideration, it demonstrates why it's so critically important that testers know how to write test cases in a variety of ways.

Test cases form the basis of testing; they document what QA needs to test and what steps are needed to verify that the code functions properly. Development teams usually create test cases from test scenarios, which describe -- at a high level -- what QA should test in terms of user workflows and end-to-end functionality.

Test cases detail both the what and the how of how tests will run. The what details what specific user story acceptance criteria a dev team will need, and the how details the steps its QA professionals will use to determine the expected result of each step.

Let's examine how to write test cases that are both effective and efficient.

How to write manual test cases

Test cases -- especially those designed for manual execution -- should put the tester in the role of the user. Therefore, the first step on how to write test cases is to develop a thorough understanding of the user story, the acceptance criteria and the functionality in question.

For example, testers should start by developing a test case for each set of acceptance criteria. However, this is where the tester should think like a user. Brainstorm the out-of-the-box ways a user might try to execute the workflow. Try hitting the back button to restart the process. Try the same with the undo and redo buttons to alleviate problems with a negative test. If the tester finds a negative test -- while viewing this experiment from the user standpoint -- it confirms that the code doesn't function how it's supposed to function.

QA professionals should design manual test cases so that anyone can execute them. As a result, these manual test case designs require careful attention to detail in each step. Although templates for test cases vary depending on the organization, the SDLC and the tool in use, all test cases should include the following components:

Title, describes what the test intends to verify and includes an identification number;
Description, explains the test objective;
Preconditions, including any configurations, data setup, tests QA professionals must execute first, etc.;
References, including links to user stories to ensure traceability;
Detailed steps, clearly written and easy to follow; and
Expected results, clearly document how the application should respond at each step.

Other components that can be useful for manual test design include priority, whether this test should be included in the regression suite or whether the test is a candidate for automation.

Test cases for automation

If a manual test doesn't fit the bill, there is always the automation route. Before engineers develop test cases for automation, it's important to select the right test cases. Testers can employ test optimization to choose cases that provide the most coverage and ensure that their automated suite handles the highest test coverage market against the fewest number of tests.

Another element to consider is cost. Testers should select only reusable test cases because automation -- particularly at the GUI level -- requires costly maintenance. Finally, follow the automation pyramid; the greatest number of automated tests should be at the unit and component levels, while the fewest should be at the GUI level.

How to write test cases for automation

Automated test case writing is a complex endeavor that also requires a slightly different approach than its manual counterpart. Test cases for automation focus on the application state transitions and data changes, which makes it even more important that each test case contain only one test.

Test cases for automation must also further break down workflows compared to manual test cases. Templates for test cases for automation vary widely based on the automation tools in use, but they should all have the following components:

Preconditions or specifications, detail how to get the application into the correct state for executing the test, including browser launch, logins, etc.;
Sync and wait statements, allow the necessary time to get the application to the required state;
Test steps, including data entry requirements, detailed steps how to reach the next required state and steps to return the application to its original state before test runs;
Comments, explain the automation approach;
Debugging statements; and
Output statements describing where to record the results.

Both manual and automated testing are critical parts of an overall test strategy. Although both manual and automated test cases serve to verify functionality, they go about it in different ways and require different test case development.

It's important that testers understand the differences and similarities on how to write test cases for manual and automated situations to create effective test cases for all situations.