How To Write Good Test Cases To Lower Costs And Lighten Work Loads

Test cases are often written so simply that someone could walk in off the street and use them to test your system. But honestly – how often do you literally bring folks in off the street to run your test cases? When you actually do bring in an outsider to test your application, it’s usually because you want to know specifically how a complete novice would spontaneously use your application.

But even then, the spontaneity would be completely lost has soon as you jam your step-by-step test case into your off-the- street tester’s hands.

Your test cases will be more effective if you limit yourself to describing them at a high level. This article will tell you about how to find the right level of detail for your test cases.

Over-documented test cases – Over-budget costs

Our instinctual over-documentation of test cases leads to a number of undesirable side effects. Right off the bat, it takes a long time to write all that text – not to mention how boring it all is!

Secondly, it’s near impossible to keep all those detailed descriptions up-to-date because the application keeps on changing, so you and your poor coworkers end up rewriting the test cases before every test run.

And then the killer: It’s almost impossible to finish writing your test cases before you see the system you need to test.

All of the above means longer development cycles and thus slower feedback to both developers and clients.

On the bright side, there are some simple techniques and approaches that can help you eliminate these downers and get on with your life. Let’s take a look at them below;

How to develop cost-effective test cases

To avoid the trap of costly, hyper documented and non-reusable test cases, you can start by asking relevant questions about the application you’re testing:

• Is application development going to go on for an extended period of time?
• Is the application’s expected lifespan long?
• Is anything in the application governed by laws and regulations?

You also need to ponder some questions about your organization:

• Are inexperienced testers going to execute the test cases?
• Will a new person be testing every time?
• Is the organization mature enough to automate regression testing?

If you can answer no to all of the questions above, you might as well completely skip writing traditional test cases and instead go straight into approaches like exploratory testing and checklist-based testing. These two approaches are effective at finding lots of defects at low cost, but in return they require experienced testers who can get by without the hand-holding guidance of test cases. They also make it difficult to repeat tests exactly, so they won’t work for regression testing or other situations that demand full traceability and test documentation.

However, if you answered yes to one or more of the questions about the application and the organization, you ought to consider how many of those long and detailed test cases you really need to be as cost effective as possible.

Basically, you shouldn’t detail any test case more than absolutely necessary and rather than write a few long test cases you should split them up into many short ones. Naturally, “absolutely necessary” varies a lot from case to case, but the point is that you shouldn’t be writing more detailed descriptions than the minimum required for your intended audience to perform their tests.

“One-Liners”

In the parts of the application that don’t require a detailed, documented step-by-step test case for technical or legal reasons, I strongly recommend that you give “one-liners” a shot. A one-liner is a test case that describes what needs to be performed in the test in a single line of text. Moreover, the one line should include the purpose of the test. As an example, we can take the login functionality in the test tool ReQtest (see illustration below):

Here follows a trivial but realistic example of a test case and a “one-liner” to test the login functionality.

The traditional test case would very quickly become obsolete and require maintenance. It also limits the tests to a specific user account, which means your test coverage is going to be narrow and you’re going to be writing lots of test cases just to cover all variations on the username and password. And finally, you’re going to have trouble reusing this test case as a general sign-in test case in multiple test scenarios, because the test case is hard-coded with a specific user account.

The “one-liner” demands that the tester understands how the application works and where to find it, but on the other hand, the one-liner will never need maintenance and doesn’t needlessly restrict the test to a specific account. An experienced tester knows how to verify different types of user names and passwords without the help of additional test cases. You can even use “one-liners” long before you know how the user interface actually looks, and testers can use them in any test scenario that requires authentication.

When detailed test cases have to be used

Obviously there are situations where “one-liners” won’t work; you still need step-by-step test cases when you test complex calculations, complicated flows, or specific combinations (although in this case decision tables can be used).

You might also need detailed test cases whenever it’s complex and time consuming to generate new test data. This is especially true if the test data is highly dependent on the workflow, if the expected outputs are difficult to calculate based on various inputs, or if the expected result is strongly dependent on the workflow.

In conclusion –

By writing your test cases at just the right level, you’ll make them more effective, and your work will be more fun. Next time we’ll specifically discuss how to reduce the maintenance costs of detailed test cases.