Positive vs Negative vs Destructive Test Cases

We have previously talked a lot about test documentation. It’s an integral part of software testing, and one of its major players is the test case. Test cases are the step-by-step sequence a tester executes in order to validate that a piece of software is functioning as intended. When writing test cases, it’s important to select the correct style for the test case you are working on.

What is the goal? To validate what the software is supposed to do? To validate what it’s not supposed to do? Or is the goal to see if the software breaks down at a certain point? In general, there are three styles of test cases in software testing that cover these approaches:

1. Positive test cases
2. Negative test cases
3. Destructive test cases

Positive Test Cases

Positive test cases test valid inputs to verify the software is doing what it’s supposed to do. The main purpose of this is to make sure the system isn’t throwing errors when it’s not supposed to. In general, positive testing ensures the system meets the requirements under positive scenarios and day-to-day use.

Examples of Positive Test Cases

Let’s consider a password creation field that should accept 5-10 characters and include only letters and/or numbers. Here are some positive test case examples:

• Password field should accept 5 characters
• Password field should accept 10 characters
• Password field should accept all numbers
• Password field should accept all letters
• Password field should accept a combination of letters & numbers

Negative Test Cases

Negative test cases test invalid inputs and verify that the software is not doing what it is not supposed to do. The intent of negative testing is to ensure the system validates against invalid inputs by throwing errors or otherwise not allowing the system to perform in a certain away. Let’s consider the same password creation field example above and look at some examples of negative test cases.

Examples of Negative Test Cases

• Password field should not accept 1-4 characters
• Password field should not accept any characters outside of numbers or letter (!@#.. etc)
• Password field should not accept 11 characters

In each of these tests, the system should not accept the input and it should result in some form of validation. The system should handle these validations gracefully, whether through error messages or other UI approaches to validation.

Destructive Test Cases

The purpose of destructive test cases is to test what the system can handle until it breaks or “destructs”. Load testing and script injections are common approaches to destructive testing. Here are some examples of destructive testing.

Examples of Destructive Test Cases

• Applying a significant load to the system which results in a failure
• Injecting JavaScript into a web form with malicious intent
• Fast-clicking in attempt to break a webpage

By performing some of these unpredictable scenarios, you’ll determine whether or not your application can handle these situations gracefully.

Applying These Test Cases Styles In Software Testing

It’s easy to test the happy path (positive test cases), but it’s important to not overlook the other two styles of test cases (negative and destructive test cases). These three styles of test cases in software testing can be applied to a variety of different types of test cases such as integration tests, non functional tests, functional tests, and user acceptance tests. These approaches to testing have varying goals and purposes, and as a result, their test cases are very different.

By considering all angles of testing and writing positive, negative, and destructive test cases, your test coverage will be greater and your product will retain a higher level of quality.