How to Write a Software Test Case Like a Pro

Writing software test cases isn’t something to take lightly. Aside from coding and testing your app, writing test cases is the third ingredient to consider in the ‘successful release’ triumvirate. Does this sound like a lot of pressure to place on a task often regarded as mere ‘writing’? It should — because it is. Poorly written test cases directly impact testing, and therefore revenue. This holds true whether we’re discussing a customer-facing or internal platform. Either type of software will suffer if test cases are designed by someone who doesn’t understand the value test cases bring to the testing process. In short, writing test cases is an adjunct to stellar development, not an afterthought.

What is a Software Test Case?

The surface level definition of a test case is quite simple. A software test case determines a set of conditions in which the software is checked to ensure requirements are satisfied, and that it functions as specified. A test case is a set of instructions covering a single instance of how and what to test. Test cases include: a title, a description, exact test steps, expected results, and observed results. Straightforward, right? Well, yes — and no. Designing test cases like a pro is more than simply writing “Check compatibility with all browsers”!

Who Writes Software Test Cases?

Other than unit tests, test cases should be written by the quality assurance (QA) team. While quality is everyone’s job, it actually is the job of QA to manage the quality process from idea to release. Pro-level test case design asks the writer to take a deep dive into the application under test (AUT) through both the business and user perspective. This sort of deep-dive creates extremely fine-grained attention to detail. Test case writers ask themselves: What is the test goal? To validate what the software is supposed to do? To validate what it’s not supposed to do? To find out if the software breaks at a certain point?

To adequately test more than the ‘happy-path’ imagined by the developers, test cases must be designed to reflect the way non-developers interact with digital offerings.

Still, simply creating test scenarios with an in-depth understanding of the AUT and its users isn’t enough. The pro test case writer will acknowledge their audience, purpose, and goal — and compose accordingly.

One method of translating test requirements into accessible ‘everyday speak’ for testers is embodied by the ‘plain-language’ movement. Plain language is writing designed to ensure the reader understands as quickly, easily, and completely as possible with a goal of being easy to read, understand, and use. Plain language avoids verbose or convoluted language, and technical jargon. This means test case writers shouldn’t feel trapped by the linguistic expectations of the developer discourse community, but also not feel compelled to ‘dumb-down’ their writing. After all, if our tester gets lost in the jargon, what good is the test case? Here, the optimal test case writer is the QA teams’ technical writer who understands the UAT, the development process, and the audience.

The Value of Test Case Design

Test cases add downstream value by enabling anyone to go in and retest using the written case. Well-written test cases can mean the difference between making or breaking functionality and user satisfaction when releasing updates or adding new features. Test cases are powerful artifacts for the future, as well as acting as a repository of information about the way a system or feature works.

Summing the value of test cases, we see the following:

• Ensures comprehensive test coverage by addressing all aspects of functionality, including business requirements, user needs, hardware variances, and out-of-spec user actions
• Properly documented test cases are reusable, allowing anyone to reference them and execute the test.
• Test case documentation acts as a knowledge-base for platform details

Now that we’ve looked at the ways well-written test cases impact software development, and the skill-sets a test case writer should hold, let’s explore a few high-level steps you can take to ensure your team writes quality test cases.

6 Tips for Writing Software Test Cases

Use a Strong Title

• A good test case starts with a strong title. Best practice indicates naming the test case to explain the module you’re testing. Example: When testing browser compatibility, a title might read “Steps to test application to browser compatibility”. Titling test cases with relevant keywords also allows for quick search referencing in test case databases.

Include a Detailed Test Description

• The description should tell the tester what they’re going to test and include any other pertinent information such as the test environment, test data, and preconditions that must be met before the test is executed (such as an OS or browser specific version being loaded)

Include Assumptions

• Include assumptions that apply to the test. This might include where the user starts the test at (order page? search page?)

Create Clear and Concise Test Steps

• Test steps should include the data and information needed to execute the test. Nothing less, and nothing more. Don’t leave out necessary details, but keep them clear and concise (see: plain language!)

Include the Expected Result

• This tells the tester what they should experience as a result of the test steps and determines if the test case is a “pass” or “fail”.

Make it Reusable

• The pro level test case is reusable and provides long-term value to both the software development and test team. When writing a test case, keep this in mind. Save time — and money — in future iterations by re-using the test case instead of rewriting it.

Final Thoughts on Designing Test Cases

Anticipating user needs, and integrating those needs with business requirements, is crucial to finessing your app before deployment. This is a job for a professional! Don’t relegate test case writing to an afterthought or view it as ‘just another administrative function’. Test case design has the potential to impact development, whether that impact is positive or negative depends on the skill of the test case writer.  Let your QA team handle test case development, and rest assured the right people are doing the ‘right things’. Oh, and don’t forget to use plain language! 🙂

Need help designing test cases? We can help!