Learn about our classification of the negative scenarios and the strategies to create those in TCD.

There are three general types of scenarios that are relevant to the discussion of negative tests in Test Case Designer.

Treat “impossible-to-test-for” scenarios differently than negative tests

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 Bound Pair feature.

...

It might be confusing at first to understand how to address negative tests in the context of generating Test Case Designer 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 TCD tests

The easiest way to handle negative tests is to simply keep them separate from your TCD-generated tests. Many teams using our tool find it easiest just to generate their positive tests. Then, outside of Test Case Designer, they will document negative tests in the same way they do currently.

...

If you decide to use this approach, consider using the “Notes” feature within TCD – 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

TCD sets of tests include scenarios that generally have the same number of steps. It is important that every test actually gets executed from start to finish. Why? Because of interactive coverage measurement. TCD tests ensure that you will achieve coverage of all of the interactions you have selected (2-way interactions, 3-way, etc.) If some of your tests stop part-way through, you will not achieve your desired coverage goal. The following example demonstrates this important point.

...

• 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

Sometimes it is simple to avoid the problem described above. You can just change the way you’re describing the Value that causes an error message to make it possible to achieve both of these objectives:

...

• Instead of entering “500” as the quantity of passengers, enter the following: “500, 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 Test Case Designer.

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:

...

If you have a script-killing test that you want to run, do not include it in your TCD scenarios. Instead, create a test for that outside of the tool.