By Ulf Eriksson, Co-founder of ReQtest
The art of test case writing might seem easy to master but it is actually fraught with perils that can cripple an agile workflow.
Test case writers have to do more than stick to routine templates if they want to help their team succeed. The ability to adapt the test case to the case being tested is a skill that can be acquired, especially by learning to avoid common mistakes.
In this article I look back at four of the worst test case scenarios I have ever seen. Each one hinders the work process in some way, and for every one I suggest simple solutions which you can incorporate in your practice.
The one that was too short
The ‘diminutive’ test case is a species that causes much frustration to a tester because you never know what might be wrong with it. Often, test cases that are too short either have missing steps in them or describe the test procedure in a vague way.
Don’t get me wrong – there are plenty of reasons why short test cases are fine in some instances, but the main problem is that a testing procedure with very few steps is rarely worth the time to write up a full test case. A better method for this scenario would be to create a checklist instead.
A checklist is like a simplified test case. Whilst the latter will contain a lot of fields to fill in and requires more content to flesh out; a checklist simple describes the steps of the operation you want to test. In certain situations you might even want to go for a “one-liner”: a single line of text that explains what should be tested.
The main point here is that if a test case is going to be very short, it is worth presenting it in a different format, like a checklist or one-liner, in order to dispel doubts that there are missing steps or be tempted to buff up your test case with useless jargon to make it seem longer.
The one that was too long
“A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.”
The advice given by William Strunk in his classic primer on writing, The Elements of Style, should ring true to any test case writer out there.
If a test case has too many test steps, you might want to break it up into a set of smaller tests. Not only does it make it easier to read and execute, but if a developer runs across an error it will be easier to isolate the bug in a short list of steps than having to backtrack and start a long test cycle from the beginning.
Sometimes, I come across over-documented test cases that make me wonder whether the test writer was aiming to write the next Ulysses.
Over-documentation not only wastes precious time for the writer who could have tackled other cases in his workload, but can lead to a number of problems in the actual testing phase.
The more details a test case has, the more effort has to be expended on re-writing the descriptions whenever an application has been tweaked – which happens all the time. This leads to longer development cycles and slows down feedback to the developers and their clients.
The test case with too much jargon
Jargon-heavy test cases are often a clear sign that the case could have written in much fewer words if simpler descriptions had been used.
Whether writers sprinkle jargon to cover up for a test case which they deem too short, or in order to give a technical impression, is debatable. However what’s not is that a test case is a pragmatic piece of writing which can do without unnecessary verbosity.
A test case is there to get a job done. Period.
There’s no need to impress somebody with it, let the finished product do all the talking. Writing a test case that’s too difficult to understand slows down testers and poses an unnecessary obstacle in the agile workflow.
The one that needed high maintenance
A test case must be written in a way that accommodates easily future changes in the application being tested.
A traditional test case quickly becomes obsolete and in need of maintenance to keep up-to-date. Limiting the purpose of a test case to a very narrow function will result in several other test cases having to be written simply to substitute or expand on it.
While this might not be the case for every test case, a case that is describing a general function (e.g. validating login credentials on a website) should be written accordingly in a general fashion which caters for multiple test scenarios rather than focussed around a specific action.
Conclusion
Many of the test writing problems described here happen because writers do not have a structure that guides them to adapt their output to the case in question.
The length of test cases depends on the context. Is the test case is going to be used for years during further refinement of the system? If you are used to review documents such as the requirements documentation, do you apply the same review techniques to test cases? If no, why not? During exploratory testing the test cases may be shorter and serve as “test ideas”, rough ideas that guide the tester in the right direction. In this case you have to develop some other method to support continued testing during the rest of the system’s lifetime.
Another problem is the lack of proper testing tools that can simplify the process and automate the basic task, leaving the writer with more time to think about how to best present a case.
Writers who are still writing test cases in Word and are seeing their workload getting bigger should think about looking into using real testing tools instead, tools built specifically to be fit to purpose.
About the author
Ulf Eriksson is one of the founders of ReQtest, an online bug tracking software hand-built and developed in Sweden. ReQtest is the culmination of Ulf’s decades of work in development and testing. Ulf is a huge fan of Agile and counts himself as an early adopter of the philosophy, which he has abided to for a number of years in his professional life as well as in private.
Ulf’s goal is to make life easier for everyone involved in testing and requirements management, and he works towards this goal in his role of Product Owner at ReQtest, where he strives to make ReQtest easy and logical for anyone to use, regardless of their technical knowledge or lack thereof.
The author of a number of white papers and articles, mostly on the world of software testing, Ulf is also slaving over a book, which will be a compendium of his experiences in the industry. Ulf lives in Stockholm, Sweden.
