When a tester is in the process of designing a set of test cases against a given piece of functionality; typically, their first thought is to create positive test cases, i.e. ensure that the functionality does what it is supposed to do. But, a stage often missed in test case design, is ‘negative testing’. This approach is just as important as positive testing and widely argued as being more important.
Looking purely from a risk perspective, the chances are that some positive tests would have already been carried out by the developer prior to handing it over to the tester. Negative tests may, or may not have been a key consideration, and so there is potentially greater risk. There are some interesting observations made by testing professionals that can be found on the internet regarding negative testing. The most common observation is that a negative test will far more likely find a defect than a positive test will. A popular test case design approach is to ensure that for every positive test case created, there is also an equivalent negative test case created. However, a greater number of negative test cases than positive test cases is a more highly regarded approach.
The result of a positive test is often quite clear, as there is typically a known expected result for the tester to verify the software’s behavior against. For negative testing, the end result can often be unclear. For example; there may be a requirement that states that the software displays certain information after a user enters a valid password. For the test case designer, designing a positive test case for this simplistic scenario is a ‘no-brainer’. Designing a negative test case for this scenario is also a ‘no-brainer’.
The interesting part comes when we consider how many more negative test cases can be produced from such a simple piece of functionality. Without much thought, a test case designer should be able to come up with a large number of negative test cases based on that simple scenario alone. The tricky part comes when writing the expected results, as each negative test may well produce a different result, unlike that of the positive test case. At this stage it’s imperative for the test case designer to consult with the developers (or design documentation) to ensure that the expected results are in fact…..expected.
The goal of negative testing is to find issues where the software does not ‘gracefully’ handle unexpected situations. As the user experience is such a key factor in the design of software these days, the term ‘gracefully’ is somewhat subjective. Therefore the expected result of a negative test case must not only consider the functionality, but also what the end user’s experience will be.
QA Tips - Negative Test Case Design
