The Case for Incorporating Test Cases into the SDLC

Test cases are just one seemingly small aspect of the larger testing process, but they help to clearly define the expectations and goals of a given test so that testers are prepared.

A test case is a set of instructions for a quality assurance (QA) tester to follow to achieve a specific outcome. For example, a test case could be written to test the values entered into a search field, with stipulations around the test conditions, like if it’s a full search, partial search, and so on.

Test cases are most often found in manual testing processes and are comprised of objective, designated steps to follow, the expected outcome, the actual output, and the pass/fail distinction. They’re documented with client requirements in mind and if any of the steps don’t produce the expected results, the entire test is given a “fail” outcome.

Test cases are meant to clarify what needs to be done in order to thoroughly test a system, application, or software product. It provides a detailed breakdown of the areas that testers should focus on to understand how the system is functioning as a whole.

This ties into the larger testing/QA process and serves as a way to measure if customer expectations were met or not.

Generally, test cases are simple and logical to write. The challenge lies in writing them in such a way that all possible outcomes are considered, so that the software or product isn’t being tested with only positive confirmations or best-case scenarios in mind.

Before a test case begins, it’s helpful to create a feature map. These are lists of all the pages in a system with high-level descriptions and lists of links or features that exist on a given page. This is helpful because it serves as a blueprint for testers to become more familiar with the software or product, and to understand the ways that different areas of the system work together or impact one another.

For a test case to be written well and executed correctly, there needs to be a high-level understanding of the software or product that’s being tested. If the internal QA team is the one rolling out these tests, they need to adopt a more exploratory mindset and consider functionality from an end-user perspective.

The process for writing test cases encompasses test analysis, test design, and test implementation.

• Test Analysis

Identifying the basis for testing is the first step in test analysis; this includes examining user requirements, user cases and stories, and more. In this phase, test conditions should also be determined, as they represent any nuances that testers should be aware of.  

• Test Design

In the test design phase, a more comprehensive picture of the test cases begins to form. Expected results are defined during design—without these points, your testers would have a lot more work associated with evaluating the test results.

By defining the expected outcome, you’re creating a target for your testers to hit so they don’t have to discern whether a test result is within the range of normal or correct.

• Test Case Execution

In this final stage, the test cases are manually rolled out by the QA team or, if the testing is automated, a tool is used to combine test cases to form test scripts. Then the outcomes can be tracked and logged depending on if they’re “pass” or “fail,” which determines next steps for the development team.

Some customers opt for employing crowdtesters for test case execution so that their internal teams can focus on the coding, correction of bugs, or other areas of testing more central to the SDLC. Using crowdtesters can also speed up the testing process. Interested in seeing how crowdtesters approach test case execution? Sign up for a free demo.