What You Need To Know About Writing Effective Test Cases
Our guest blogger this month is Valerie Dale – one of the first (and finest) testers to join our global community. In this post, Valerie will address the importance of writing clear and effective test cases for specific audiences. 
Despite all evidence to the contrary, test case design is often seen as work with no real value – a remedial task with no significant ROI. This is puzzling on a number of levels. One would think that with the added pressures to launch a quality product on schedule, test case design and planning would be a top priority. It’s not. At best, there is minimal attention paid to the practice. At worst, it’s non-existent.
But test case design is an important part of the tester’s, or test designer’s job. Without some type of design or planning, it is possible (likely, in fact) that critical requirements and defects will be missed. In actuality, test case planning/design can be the single greatest factor in the success of a release.
Most people define test case design by considering which tests to execute for boundary conditions, error handling, data types, data validation, etc. While these items are the meat of the test cases, there are many other things to consider, as test case planning/design is comprised of several thought processes and each plays a part in determining whether or not the test cases will be successful.
For instance, thought should be given on how to group the test cases together into a test procedure document or script. To illustrate, here’s one question to ask yourself: “Can I combine test cases, which have the same input and process, into one test case so I can verify/satisfy more than one requirement with one set of steps”?
As an example, let’s say you have three requirements and one test case for each requirement. Each test case has the same input and process. By combining the Expected Results for each of the three test cases into one, you now have one test case and three Expected Results. Your test execution time for these three requirements has essentially been reduced by 66% and each requirement is still being verified.
Another question suitable for consideration is this: “Can I group the test cases so the output of one test case becomes the input of the next test case”? Arranging test cases in this fashion provides for a better execution flow or progression of events. Being able to arrange test cases in either (or both) of these scenarios saves time during test execution because redundancy has been eliminated.
Test case design/planning also needs to include consideration for the audience of the test procedures. Test cases can range from a very detailed (step-by-step actions) to high level (describes the action but leaves the actual steps to the tester). If the tester has a vast knowledge of the application, you can opt for the high-level writing style. However, if the tester is just learning the application, the detailed writing style would be a better fit.
When using the high-level style of writing, it is best to include a caveat at the beginning of the test procedure explaining the expectation of the tester’s knowledge. Other audience groups may include Development, management staff and even the customer, which means you may have to adopt a writing style to fit one or all of these groups as well.
Also, be aware of possible issues created by the writing style you choose. The detailed writing style takes more time to write and execution can lead to boredom if the test procedure will be manually executed repeatedly by the same person. This is referred to as the “robot” syndrome and restricts the tester’s ability to “think outside the box” or to try something different. It also lends itself to missing issues because the tester is looking only at the Expected Results.
The high-level style of writing takes less time to write, gives the tester greater flexibility in execution, which can lead to ad hoc testing but can sometimes make repeatability difficult. (Ad hoc testing is often frowned upon because it is not “structured” testing and has a tendency to increase execution time).
Whichever approach or style you choose, make sure it fits your environment and your time constraints.
[...] What You Need to Know About Writing Effective Test Cases – by Valerie Dale [...]
You have made some good points about writing test cases, essentially it comes down to the classic technical writing problem of knowing your audience.
Technical writing people like to do end user analysis, task analysis and environment analysis in preparation for writing, it may be prudent for test case designers to do the same.