Achieving quality test case design
The concept of the test case is simple enough to understand. It is merely a list of actions designed to test a particular feature or function of the application being tested. It nevertheless has to be communicated not only to the testers, but to any other relevant stakeholders as well. This is why it's a good idea to name your test cases in a way that is easily understandable to anyone who is going to refer to them. The name should not be obscure or use letter and number combinations that require looking up the test in some logbook. Rather it's best to reference the function or module in the name itself. Remember, keep it simple when naming test cases.
Test cases should also be maintainable in the face of changes. Changing requirements should not require the reworking of a larger number of test cases. Part of this is ensuring that no test cases have unnecessary steps. All steps should be necessary and needed. It's possible to lose focus if there are too many steps and it's also possible that a large number of steps can cause the test case to become invalid in the face of changing requirements. There is such a thing as too much detail and test cases should be adaptable as requirements change.
Also, testing scenarios should not cover more than one function at a time. There should be a single expected result and not a multitude of results for a given scenario. And it's also important to make certain that the test case is traceable, because this will help ensure 100% coverage for all requirements and keep a record of who performed what test.
Test cases should be easy to understand. Steps should be carefully delineated and specific so that testers can easily perform them and one tester can, if necessary, pick up where another tester left off. Consequently, the more the test case is self explanatory and its scope and purpose is clearly detailed, with all test data specified, the easier it is for testers to perform and the faster the testing lifecycle can be completed.
Competent test case writing can lower testing costs and technical support costs over the lifetime of the product by making sure that releases function fully and do not accidentally turned users into beta testers. In this sense it also ensures that the application under test conforms to all necessary regulations, especially with regard to accessibility. It can also measure performance from the user's perspective, such as how entertaining a game might be or how easy the software interface is to use.
Test case scenarios can also assess the quality of application in a three dimensional way that goes beyond module functionality. It can determine how loss of data or poor data processing can affect operations and influence safety concerns as well as how well the application fits into the data environment. In short, quality test case scenarios can enhance reliability by pointing to those areas that may require ad hoc testing. In this way the quality of the product can be assured and its correctness in relation to documentation can be determined.
This is why it is important to develop tests that are as powerful as possible, in the sense that they can look for and find the most important bugs while yielding results that enable a successful release and are important to stakeholders. This means that ad hoc testers may sometimes need to control their imagination and not wander off into “corner cases” involving subjecting the application to things that people would never do. This is another reason why it is important to have skilled testers. If you set up your tests to evaluate performance within rational parameters, it then becomes easier to push the edge of the envelope in ad hoc testing as those edges have been clearly established.
Well written test cases can do more than just finding defects. They can keep products from being shipped prematurely by finding crash level bugs, and they can help managers decide when to ship by providing data regarding known problems. They can also show how much of the product has been covered by testing and whether or not problems, which may have appeared significant, can actually be easily dealt with. Quality testing is more than just maximizing the bug count. It is a part of the development cycle that has important influence in a number of areas. Quality testing shows that performance conforms to specifications, that the application can function within the intended environment and will not crash when confronted with wrong input or high demands.
When writing test cases you should keep in mind that testing primarily exists to reduce uncertainty. In this sense, we learn from every test we do. We learn whether the program passes or fails. Passing increases confidence and moves the application closer to release, while failure reveals faults that we didn't know were there, we learn in either case. So test case design should lead toward those tests which most readily increase certainty.
There is no simple paint by numbers way to write test cases. It would be nice if there was a formula or series of formulas that, when followed, would always yield precise results. The tendency is to stick to a small variety of tests. While this can lead to predictable results, it must be remembered that no particular batch of tests will cover every contingency. It is always best to use a wide number of techniques to ensure the best possible results.