.png){kind=icon}
One of the most essential components in the practice of QA testing is the test case. Test cases outline the specific set of steps manual testers take to test the quality of Web and mobile apps, connected objects, software, and more. They’re the road maps, essentially, of all the different ways users might interact with an application — and they allow testers to make note of any bumps in the road. We believe that a test case should be so well-written and so clear that anyone (professional or not) can execute it. And while there’s no one right way to create test case, there are a few crucial elements that are key to creating an effective, efficient one.
Singular ID
Every test case should start with a unique ID. You can link a specific test case ID to a requirement ID in a functional specs document or to an issue in JIRA. And linking bugs in test cases to design/functional requirements bridges communication between QA, developers, and project managers.
Scope and Schedule
As with any project, the scope of work clarifies what will get done and how. While it doesn’t need to be included in the test case, it’s a foundational first step in the process of creating one. This is where you’ll highlight details such as users, deliverables, the timeline, reporting, and more. It’s also helpful to include design mockups, wireframes, and technical specs, if they’re available. Getting clear on the scope of work also makes sure you cover all user scenarios in your test case, and helps you direct testers on how best to proceed with testing.
Strategy and Specs
Your strategy or test plan is another foundational aspect of your test case. It outlines specific details about your project and helps you map out test execution. Important specs to include are the scope (see above), objectives, the resources (like types of devices), and the types of testing to execute. Much like the project scope, your test strategy is often created by a project lead and not included in the test case. However, it’s also integral to the development of a test case that is specific to your app and your users.
Scenarios for Every User
The objective of effective testing is not just to find out what’s not working as it’s meant to, but to emulate the user experience and ensure it’s optimal. The next step in creating an effective test case is getting clear on those experiences. There are a number of different ways users might navigate an app, and test cases must take into consideration each of those standpoints. Rebecca Boardman, head of quality assurance at Reading Room, told eConsultancy that: “It’s also really important to ‘think outside the box’ when it comes to testing. Sure, most of us on the project know how the piece of software is meant to work and what the logical user journeys are, but will the general public using this software know that?” Agreed. Creating realistic user scenarios is about getting into the heads of the users, and testing for quality and satisfaction much as they would.
Steps (and Sub-Steps, Too)
Once you’re clear on the individual user scenarios, it’s time to build the bulk of any test case: the steps. Every user scenario is made up of various steps (e.g., launch the app, press the back button, etc.), and in a test case, each of these steps is a direction for the tester: “Next, try this and see if it works the way it’s intended to.” While it’s important to be detailed, it’s also helpful not to be so detailed that your tester spends more time reading the instructions than trying to intuitively understand and use the app. Additionally, consider that sometimes multiple testers will execute test cases across different platforms, so the steps will differ based on the operating system or device with which they’re testing. This is where it’s important to let your testers think outside of the box — like actual users — too. Give them the guidance they need, and trust that they’re trained to find the way.
Skilled Communication
Finally, you have the results. Effective testers must be able to communicate both the expected result and the end result in a way that is clear, unbiased, concise, and communicable to varying different roles on the project. This feedback also indicates where a certain step has passed or failed. Good communication is important not just between testers and developers, but within testing teams as well. If a test case isn’t clear or doesn’t match the app being tested, then that should be quickly communicated to the project lead. Results must be not only accurate, but easy to understand, so that developers can implement changes efficiently and without a lot of back-and-forth.
* * *
As you can see, there’s a lot that goes into creating and managing every single test case (and testers wear a lot of hats!). So if you’re not interested in writing your own QA test cases, we get it — and we’ve got you covered! Get in touch with us to learn more about how to create test case, our testing services (and our comprehensive test cases) at PLUS QA.