Writing good test cases — How hard can it be?

What are test cases? Can’t we test without those?

At a glance, a test case is a documented procedure on how to test something. It puts together a set of steps to follow when testing the functionality under test and provides the expected outcomes for each of those steps.

Can we test without those? well, practically it is possible — given the product is mature and the tester is well experienced in testing the particular functionality under test.

But the more important point would be ‘should we test without test cases?’, to which the prudent answer would be ‘no’ — the reason is, as with anything, one should know what to do and when. This ‘what to do’ is defined in the test cases and ‘when to do’ is set by prioritizing the test cases. Of course, there could be deviations to this in practical scenarios (eg. when using experience-based or defect-based testing methods) but a set of well defined and prioritized test cases could be the better strategy to follow.

Is a ‘Bad Test Case’ actually a thing?

Yes :)

As mentioned before, a test case could simply be a set of steps to follow with their expected outcomes. Some organizations may even adopt the standards such as ISO/IEC/IEEE 29119–1:2022 or even the older IEEE829 — which could help improve the test cases. Either way, the quality of the test cases lie in the hands of the test engineer who prepares those.

To put it bluntly, if a test case does not clearly states what it tests, what steps to follow and what are the expected outcomes for each steps, it can be considered as a ‘bad test case’.

What counts in as a good test case?

On the flip side, even a person who is not familiar with the application under test should be able to understand what to do and what to expect by the particular test case. It should be possible for such a person to objectively determine whether the specific functionality addressed by the test case is working as expected.

How do I write a good test case?

Preparation

In order to get the most out of a test case, it should be clear what functionality or the requirement it addresses. To get there, the person who prepare the test case should be well aware about those. That’s the first step of preparation.

As the second step, a set of actions to follow for each test case and the relevant outcomes which are expected when each of those actions are executed should be identified. Ideally it should be possible to execute these actions in sequence. The expected results are the assertions that verify the outcome.

Design

It is possible to test everything. But “Exhaustive testing is impossible”

Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, we use risks and priorities to focus testing efforts — ISTQB

This is where the test design techniques come to help. While it is a different topic to discuss on its own right, the techniques such as equivalence partitioning, boundary value analysis, decision tables etc. can be used appropriately to identify an optimal set of test cases which should suffice to cover the software under test comprehensively.

Critical components

In practical situations, test management software are used to manage the test cases at organization level. Depending on the product, the components supported to be in a test case could vary. However, the following basic components should be there:

A summary/ title — to briefly state what the test case does. This appears in the test case lists and reports. So it should be possible for someone who goes through those to figure our what a particular test case does at a glance by looking at its title.

Pre-conditions — to state what are the conditions that should be present before executing a particular test. The user being logged in or an app is being started are some examples.

Steps and expected results — these are the most critical items in the test cases. The significance is discussed above.

‘Automatability’

When a test case is prepared, more often than not, it is expected the said test to be automated at some point of it’s lifetime. Therefore it is vital that the test case prepared in such a way that it is automatable even at a later time.

In order to be so, certain characteristics of the automation suite — such as it’s structure, tool capabilities, existing test scripts, pre-condition setup etc. — should be taken in to account when preparing the test cases.

One key important point to consider here is how the assertions are handled in the test automation suite which is going to be used. The way the expected results are stated in the test cases should be mappable to that.

End Remarks

In order to test something — especially software — requires a unique mindset. The skills of a tester with such mindset is demonstrated by the way the person prepares their test cases. A well tested software is always at the preferable side of a comparison scale of customer. A set of good test cases is the hard to come-by outcome from a good tester, which could decide the future of such software product.