How to Handle Negative Testing in DesignWise
Learn about our classification of the negative scenarios and the strategies to create those in DesignWise.
There are three general types of scenarios that are relevant to the discussion of negative tests in DesignWise.
Impossible-to-test-for scenarios involve combinations of test inputs that will NEVER appear together in the real world. A good example would be using an Apple computer’s Operating System and trying to launch Internet Explorer. It cannot be done under typical circumstances. There is no point in trying to test for it, because Internet Explorer has not been available on Mac computers for years. The appropriate way to handle these scenarios is to simply prevent them from appearing in your tests using the Invalid Pair or Married Pair feature.
Negative Tests are different. You want to include certain scenarios in order to confirm, for example, that certain types of users will not be able to perform certain actions. If you had different types of users for an airplane reservation system, for example, you might want to confirm that no role other than a Super-Admin User would be able to modify the ticket price. It is important to test for these kinds of scenarios.
It might be confusing at first to understand how to address negative tests in the context of generating DesignWise tests, but the effort you make to clearly understand your negative testing options will be well worth it because this topic comes up frequently in most projects.
Advice for Beginners: Keep negative tests separate from DesignWise tests
There is nothing wrong with this approach and it has the advantage of being “clean” and easy to explain. Depending upon your teams tools and processes, and perhaps the quantity and nature of the particular negative tests you have in mind, it might be an appropriate solution for you.
If you decide to use this approach, consider using the “Notes” feature within DesignWise – some teams document their ideas for negative tests there to make sure they don’t get lost.
Advice for Intermediate / Advanced Users: Distinguish between types 2 and 3
Imagine that you have a test that says:
Fly from: India
Fly to: France
Departure Date: Tomorrow
Class of Travel: First
Number of Passengers: 500 <
Meal Preference: Vegetarian
Type of Discount Available: XYZ
Payment Type: CC, Cash, FF Miles
Print ticket: Online, Email, Snail Mail
- From India & Vegetarian
- To France & FF Miles
- Depart Tomorrow& XYZ Discount type
- First Class Travel & Snail Mail
- etc.
Advice for Intermediate and Advanced Users: Consider including negative tests that allow execution of every step
- Trigger the error message to complete your negative test, and
- Enable the tester to fix the problem and proceed to the end of the test.
In the flight reservation example above, here’s how we could change the description of the Value we enter into DesignWis to accomplish both of those goals:
- Instead of entering “500” as the quantity of passengers, enter the following: “Enter ‘500 passengers,’ then confirm that the correct error message appears, then enter a valid number of passengers.”
Problem solved.
Beware of negative test ideas that would kill any of your test scripts before the final step. Document those outside of DesignWise.
The example above assumes that a tester would be able to trigger an error message with an invalid entry, and then fix the problem that caused it and continue onwards to execute the entire test script. Sometimes, though, a tester might not be able to fix the problem nor continue executing steps. The following kind of test for an ATM is an example of a “script-killing” test:
“Confirm that when an ATM user enters their PIN incorrectly 5 times, then the machine should physically destroy the user’s card.”
If you had a set of tests that involved multiple steps and were supposed to happen after the user entered their PIN code, such as withdraw a certain amount of money from a certain type of account, you would run into the problem described immediately above. Important combinations of test inputs would not be tested. In this example, there is nothing that a tester would be able to do after the card was physically destroyed; it would not work to say, “now fix the problem and continue executing the test.” It would be impossible to resurrect the card once it had been physically destroyed.
If you have a script-killing test that you want to run, do not include it in your DesignWise scenarios. Instead, create a test for that outside of the tool.