How to approach test case design

Build up the test case design

Test scenarios are at the highest level of test case design. These scenarios describe the functionality that's under test, often from the perspective of the user. Testers typically break these end-to-end sequences into multiple test cases.

Test procedures and test cases are similar, as each contains the actual steps to execute the test. Some people use procedures and cases interchangeably. Others define a test procedure as a grouping of exercises that verify specific functionality, and a test case as being both the steps to execute the test and the expected result of each step. The purpose of a test case is to verify that application functionality works according to specifications.

For our purposes, we'll define a test procedure as a type of test case. Yet, unlike a typical test case, a test procedure might not contain the expected results for these steps.

Test suites are groupings of test cases, typically based on features, functionality or test type. For example, a QA team might develop a regression test suite, or select tests for automation based on what is grouped together into a particular suite.

Determine what to test

Test case design begins with requirements. If QA professionals create tests based only on the application, they can only test that it works, not how stakeholders want it to work. This distinction is critical. Requirements are the source of truth -- from which one builds test cases.

Testers can create test cases from many types of requirements, depending on what must be verified. For example, design specifications are useful when testing microservices, APIs or validations of data flows and transformations. To devise test cases for usability of an application feature, the most helpful assets might be personas, archetypal characters who represent user groups, and user value stories, users' expectations for what they will gain from the software.

QA professionals should base functional test cases on business requirements, use cases and user stories with acceptance criteria.

User stories, a part of the Agile methodology, break requirements down into the smallest possible user-facing feature. User stories describe who performs an action -- and what the action is, as well as the benefit they expect to achieve. For example: A customer service representative wants to perform a search by customer name, so they can immediately find an account number associated with the person.

Testers should write acceptance criteria for user stories in the Given-When-Then format. Given describes the situation, When describes the action taken, and Then describes the outcome that satisfies the conditions of the user story. User stories, together with acceptance criteria, remove ambiguity and enable QA engineers to easily design test cases that confirm the fulfillment of desired functionality. An example of acceptance criteria might read: Given a caller doesn't remember their account number, when the customer service representative searches by name, then the software should display the caller's account number.

Use cases are also essential components of test design, especially for end-to-end testing. These lists of steps or interactions document user paths through the application. Use cases typically include both happy paths and alternative paths, where the user encounters error messages. Alternative paths are a helpful source of truth for negative test cases, which prove that the application does not perform as expected.

All QA engineers must hone their test case design skills, regardless of experience or specialty. Test cases form the basis of all testing, from unit to integration to end-to-end systems work. This standard holds true across different methodologies, including Waterfall, Agile and DevOps. QA professionals ultimately look to requirements of all types to determine what to test.