Tag Archives: test case

A Good Test Case Is?

I’ve recently been reading through my ISEB Practitioner notes, which I got when attending a course organised by Grove Consultants a few years back, as I mentioned in my previous post. It’s got me thinking about test cases, and in particular the four criteria of a good test case. Having attended both Rapid Software Testing and Rapid Test Management recently, and having rolled out an Exploratory and Session Based Test Strategy in my teams then it’s caused me to question again the validity of test cases and the need for them.

So, to a good test case. Reading my notes, a good test case is, in no particular order, apparently:

1. Exemplary.
2. Evolvable.
3. Economic.
4. Effective.

Straight from the ISTQB/ ISEB of course. But not without merit. Are these still relevant?


Good test cases can test more than one condition at the same time. This is one good reason for taking the time to design test cases in the first place. Just writing test cases because “it’s the done thing” or “because the policy says so” is time wasting, but designing them so that when the testing is carried out it is done so in the most efficient way requires exemplary test cases and can add value. It is also the case that test cases are shared and it’s difficult, especially in large organisations, to ensure that all testers have the same basic level of ability. Having test cases can help.


From a contextual point of view perhaps a good test case is not written down at all but merely in the testers head, and driving the testing into particular areas that the tester feels are worthy of time and effort. Cases where the software is the specification are becoming increasingly common; in-sufficient or non-existent requirements documentation which requires the tester to apply their previous knowledge of the system under test in order to effectively test it. Clearly in this case, if documented test cases are required then they will be need to evolve. As Rapid Software Testing mentions “How do you invent the right tests at the right time – evolve them with an exploratory strategy”.


Time is money and often in testing we have little time and sometimes little money. So using that time and that money in the most efficient way means we minimise the economic impact. Of course, sometimes the best way to get maximum value is to have a purely exploratory approach and spend more of the time and money with the software in hand. A choice which is key to a good test strategy and highly dependant on the industry area one is testing within.


Clearly a good test cases should be effective. We are not in the business of wasting time, particularly when time is precious as it often is in testing projects.


I’d argue that the definitions given in ISEB/ ISTQB are still relevant and can be a good guide as to what is required of a test case. In a lot of industries test cases are still very much required and, particularly where there is strict regulation such as in areas of financial software and even in mobile software. The ability to write a good test case is a skill which should not be forgotten.



Rumours of the Death of the Test Case

The picture above shows Samuel Langhorne Clemens, better known by his pen name of Mark Twain. You may remember him as the author of Huckleberry Finn, and a number of other books. Why is he here in this post about testing on this blog about testing? Well Mark Twain was also the author of this famous quote, which came about when his obituary was published in an American newspaper while he was still very much alive:

The rumours of my death have been greatly exaggerated”. 

 Recently there has been a lot in the testing press, online and on social networks regarding the death of test cases. “Test cases are so 1980’s” was one tweet I saw. I looked at this and thought “Why?” Why are test cases suddenly out of date or dead, why is scripted testing suddenly seem as a bad thing? Are people just trying to be cool, thinking only exploratory testing or session based testing is needed and test cases are suddenly obsolete?

I think there is a place for both disciplines and it seems others agree with me. Sure, test cases that add no value, and test cases which are merely endlessly repeated by testers who are thinking more about what to have for dinner tonight than what they are testing, are of course worse than useless. They give you a false vision of quality, a sense that everything is OK when clearly it is not. Where testing should add value and provoke debate and opinion they merely suppress the discipline to ‘button pushing’. But the act of designing a good test case, of spending the time and brain power to ensure that the system under test is exercised in a clear, efficient and repeatable way can only be a good thing. It should not be reduced to something that is perceived to be out of date, stuck in the 80’s or worthless. It’s still a very valuable tool in the testers arsenal, allowing them to get an upfront view of the changing requirements of the system they are testing and to document in a clear and consistent way how they intend to test.

Scripted testing and exploratory techniques should sit hand-in-hand. Both add value. In my experience you need both. An illustration of context driven testing is The essential value of any test case lies in its ability to provide information (i.e. to reduce uncertainty).” A good test case does exactly that. It provides information. It can help show a system will be testable at a point where that system may not even be is testable. It enables others to learn the system and it provides a way of sharing information between those working on the system and outside of it. No two testers have the same level of experience. Test cases can enable consistency in the areas of a test strategy where that is needed. In the case of regulatory approvals and safety critical systems then they are mandatory anyway.


So let’s not let the test case become an old, out-of-date idea. Let’s make sure that it’s one technique we use as part of a well-rounded test strategy whose aim is to add value to whatever system we find ourselves testing.