How to reduce the maintenance costs of detailed test cases

We recently discussed why test cases could be much more effective if you limit yourself to describing them at a high level. However, even if you have to have detailed test cases, you can do a lot of things to reduce the cost of maintaining your test cases. Below are some examples of this.

Cut down on details in step descriptions

Even if you have to write step-by-step descriptions, you can choose the level of detail at each step. Just follow the same principles described in this blog post for the entire test case.

The basic rule is to not detail any step more than absolutely necessary, or write a few steps with long instructions in each step. Instead, divide them into many steps with brief instructions. “Absolutely necessary” means you only show what must be done, not exactly how to do it.

Don’t hard code test data in the test case

If you hard code test data in the test case, you’re going to have a hard time reusing it flexibly. Instead, replace the test data with a parameter that refers to a separate document or a database containing test data. This is called parameterizing and it makes it even easier for you to reuse the test case with many different variations of the test data.

In the example below, you can see how in the first test case hard-codes account data and expected results, while the next few test cases refer to a separate test data document Testaccounts.txt containing test data.

 

 

 

 

 

 

The file testaccounts.txt can contain the following information:

 

In order to make it easier to reuse test cases between projects and in the handover to maintenance, it’s more important to describe the desired properties for test data than to provide specific values. This is true even when you parameterize the data.

 

Build test cases modularly to lowering maintenance costs

It’s really important to think about how you structure and divide your test cases to make them as reusable as possible. If for example, you need to write test cases to test the flow below, you should write a short test case for each function, rather than writing a huge test case that tests the entire flow.

If you do want to test the entire flow, you just tie the different test cases to a test run. That way, you can reuse the same test cases even if the flow changes, merely re-tying them together into a new scenario that reflects the new flow. This approach even works for “one-liners”.

 

Another benefit you get by splitting your test cases by function is that you only need to change one test case when, for example, the “Select product” functionality changes. If you hadn’t split test cases by function, you would have to change it in every test case involving the “Select product” functionality. Functionally-divided test cases reduce your need to maintain and rewrite your test cases, thus cutting maintenance management costs.

In conlusion

By writing your test cases at the right level, you’ll make them more effective, and your work will be more fun. Test runs are a great approach that will reduce the number of test cases you need to change when system functionality changes.

We recently discussed why test cases could be much more effective if you limit yourself to describing them at a high level. However, even if you have to have detailed test cases, you can do a lot of things to reduce the cost of maintaining your test cases. Below are some examples of this.

Cut down on details in step descriptions

Even if you have to write step-by-step descriptions, you can choose the level of detail at each step. Just follow the same principles described in this blog post for the entire test case.

The basic rule is to not detail any step more than absolutely necessary, or write a few steps with long instructions in each step. Instead, divide them into many steps with brief instructions. “Absolutely necessary” means you only show what must be done, not exactly how to do it.

Don’t hard code test data in the test case

If you hard code test data in the test case, you’re going to have a hard time reusing it flexibly. Instead, replace the test data with a parameter that refers to a separate document or a database containing test data. This is called parameterizing and it makes it even easier for you to reuse the test case with many different variations of the test data.

In the example below, you can see how in the first test case hard-codes account data and expected results, while the next few test cases refer to a separate test data document Testaccounts.txt containing test data.

 

 

 

The file testaccounts.txt can contain the following information:

 

In order to make it easier to reuse test cases between projects and in the handover to maintenance, it’s more important to describe the desired properties for test data than to provide specific values. This is true even when you parameterize the data.

 

 

Build test cases modularly to lowering maintenance costs

It’s really important to think about how you structure and divide your test cases to make them as reusable as possible. If for example, you need to write test cases to test the flow below, you should write a short test case for each function, rather than writing a huge test case that tests the entire flow.

If you do want to test the entire flow, you just tie the different test cases to a test run. That way, you can reuse the same test cases even if the flow changes, merely re-tying them together into a new scenario that reflects the new flow. This approach even works for “one-liners”.

 

Another benefit you get by splitting your test cases by function is that you only need to change one test case when, for example, the “Select product” functionality changes. If you hadn’t split test cases by function, you would have to change it in every test case involving the “Select product” functionality. Functionally-divided test cases reduce your need to maintain and rewrite your test cases, thus cutting maintenance management costs.

In conlusion

By writing your test cases at the right level, you’ll make them more effective, and your work will be more fun. Test runs are a great approach that will reduce the number of test cases you need to change when system functionality changes.