What is Negative Testing and How to Write Negative Test Cases?

In this post, we will discuss in detail what is negative testing and how to write negative test cases. Let’s get started.

Having the most optimal product quality is the primary goal of test organizations.

With the help of an efficient quality assurance process, test teams attempt to find maximum defects during their testing, thereby ensuring that the client or the end user of the product does not see any abnormalities with respect to its functioning in their own computing environment.

Since finding defects is one of the main goals of a tester, he/she needs to carefully design the test scenarios to make sure the particular application or product effectively performs the way it is supposed to.

How to Write Negative Test Cases

While it is definitely important to verify that the software performs its basic functions as intended, it is also equally important to verify that the software is able to efficiently handle an abnormal situation.

It is obvious that most of the defects arise out of generating such situations with reasonable and acceptable creativity from the testers.

Most of us are already aware of the different kinds of testing such as functional testing, sanity testing, smoke testing, integration testing, regression testing, alpha and beta testing, accessibility testing, etc.

However, everyone will agree that whatever category of testing you perform, the entire testing effort can be basically generalized into two categories: positive testing paths and negative testing paths.

Let’s proceed with the next section whereby we discuss what positive and negative testing is and how they’re different. We will look into a few examples to understand what kind of negative tests can be performed while testing an application.

What is Positive and Negative Testing

Positive Testing 

Positive testing is often referred as “Happy path testing”. It is generally the first form of testing that a tester would perform on an application. This is the process of running test scenarios that an end user would run for his use. Hence, positive testing entails running a test scenario with only the correct and valid data.

If a test scenario doesn’t require data, then positive testing would require running the test in exactly the manner in which it’s supposed to run and hence to ensure that the application is meeting the specifications. 

Sometimes there may be more than one way of performing a particular function or task with an intent to give the end user more flexibility or for general product consistency. This is called alternate path testing which is also a type of positive testing.

In alternate path testing, the test is again performed to meet its requirements but using a different route than the obvious path. The test scenario would even consume the same kind of data to achieve the same result.

It can be diagrammatically understood from a very generic example described below: 

A is a starting point and B is the endpoint. There are two ways to go from A to B. Route 1 is the generally taken route and Route 2 is an alternative route. Therefore in such a case, happy path testing would be traversing from point A to B using Route 1 and the alternative path testing would comprise taking Route 2 to go from A to B. Observe that the results in both the cases are the same. 

Negative Testing 

Negative testing is commonly referred to as error path testing or failure testing. This is generally done to ensure the stability of the application.

Negative testing is the process of applying as much creativity as possible and validating the application against invalid data. This means its intended purpose is to check if the errors are being shown to the user where it’s supposed to be, or handling a bad value more effectively.

It is absolutely essential to understand why negative testing is necessary.

The application or software’s functional reliability can be quantified only with effectively designed negative scenarios. Negative testing not only aims to bring out any potential flaws that could cause serious impact on the consumption of the product on the whole but can be instrumental in determining the conditions under which the application can crash. Finally, it ensures that there is sufficient error validation present in the software.

Example

If you need to write negative test cases about a pen. The basic motive of the pen is to be able to write on paper.

In this case, some examples of negative testing could be:

• Change the medium that it is supposed to write on, from paper to cloth or a brick and see if it should still write.
• Put the pen in the liquid and see if it writes again.
• Replace the refill of the pen with an empty one and check that it should stop writing.

Practical Examples of Positive and Negative Testing

Let’s take an example of a UI wizard to create some policies. In the wizard, the user has to enter textual values in one pane and numerical values in another.

First pane

In the first one, the user is expected to give a name to the policy as shown below:

Let’s also get some ground rules to make sure we design good positive and negative scenarios.

Requirements

• The name text box is a mandatory parameter
• The description is not mandatory.
• The name box can have only a-z and A-Z characters. No numbers, special characters are allowed.
• The name can be maximum 10 characters long.

Now let’s get to design the positive and negative testing cases for this example.

Positive test cases: Below are some positive testing scenarios for this particular pane. 

1. ABCDEFGH (upper case validation within character limit)
2. abcdefgh lower case validation within character limit)
3. aabbccddmn (character limit validation)
4. aDBcefz           (upper case combined with lower case validation within character limit)
5. And so on

Negative test cases: Below are some negative testing scenarios for this particular pane.

1. ABCDEFGHJKIOOOOOKIsns      (name exceeding 10 characters)
2. abcd1234                  (name having numerical values)
3. No name supplied
4. sndddwwww_           ( the name containing special characters)
5.  And so on.

Second pane

In the second pane, the user is expected to put in only numerical values as shown below:

Here, let’s establish some ground rules as well:

Requirements

• The ID has to be a number between 1- 250
• The ID is mandatory.

Therefore here are some positive and negative test scenarios for this particular pane.

Positive test scenarios: Below are some positive testing scenarios for this particular pane.

1. 12 (Entering a valid value between the range specified)
2. 1,250 (Entering the boundary value of the range specified)

Negative test scenarios: Below are some negative testing scenarios for this particular pane.

1. Ab               (Entering text instead of numbers)
2. 0, 252        (Entering out of boundary values)
3. Null input
4. -2                 (Entering out of range values)
5. +56             (Entering a valid value prefixed by a special character)

Basic Factors that Help in Writing Positive and Negative Tests 

If you closely observe the examples given above, you will notice that there can be multiple positive and negative scenarios. However, effective testing is when you optimize an endless list of positive and negative scenarios in such a way that you achieve sufficient testing.

Also, in both these cases, you will see a common pattern on how the scenarios are devised. In both cases, there are two basic parameters or techniques that form a basis for designing sufficient amounts of positive and negative test cases.

The two parameters are

• Boundary value analysis
• Equivalence partitioning

Boundary Value Analysis

As the name itself implies, boundaries indicate limits to something. Hence this involves designing test scenarios that only focus on boundary values and validate how the application behaves. Therefore, if the inputs are supplied within the boundary values then they are considered to be positive testing and inputs beyond the boundary values is considered to be a part of negative testing.

For example, if a particular application accepts VLAN Ids ranging from 0 – 255. Hence here 0, 255 will form the boundary values. Any inputs going below 0 or above 255 will be considered invalid and hence will constitute negative testing.

Equivalence Partitioning

In Equivalence partitioning, the test data are segregated into various partitions. These partitions are referred to as equivalence data classes. It is assumed that the various input data (data can be a condition) in each partition behave the same way.

Hence only one particular condition or situation needs to be tested from each partition as if one works then all the others in that partition are assumed to work. Similarly, if one condition in a partition doesn’t work, then none of the others will work.

Therefore it’s now very apparent that valid data classes (in the partitions) will comprise of positive testing whereas invalid data classes will comprise of negative testing.

In the same VLAN example above, the values can be divided into say two partitions.

So the two partitions here would be:

• Values -255 to -1 in one partition
• Values 0 to 255 in another partition

 Conclusion

Many times, I have been faced with the situation where people believe that negative testing is more or less a duplication of the positive testing rather than believing the fact that it substantiates the positive testing.

My stance on these questions has always been consistent as a tester. Those who understand and strive for high standards and quality will doubtlessly enforce negative testing as a must in the quality process.

While positive testing ensures that the business use case is validated, negative testing ensures that the delivered software has no flaws that can be a deterrent in its usage by the customer.

Designing precise and powerful negative test scenarios requires creativity, foresight, skill and intelligence of the tester. Most of these skills can be acquired with experience, so hang in there and keep assessing your full potential time and again!

About the Author: This is a guest article by Sneha Nadig. She is working as a Test lead with over 7 years of experience in manual and automation testing projects.

Let us know your thoughts and experience with negative testing in the comments section below. We would love to hear from you.

PREV Tutorial | NEXT Tutorial