What is Negative Testing? How to Write Negative Test Cases & Scenarios

Deeply discover the meaning of Negative testing and learn how to write Negative test cases. Explore more about the classification of Positive and Negative test scenarios with examples:

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, ensuring that the client or the end user of the product does not see any abnormalities concerning its functioning in their computing environment.

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

Guidelines for Negative Test Cases

While it is important to verify that the software performs its basic functions as intended, it is equally important to verify that it can efficiently handle an abnormal situation. Testers generate most defects through creative situations.

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, we can generalize the entire testing effort into two categories: positive testing paths and negative testing paths.

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

What is Positive and Negative Testing

Positive Testing 

Positive testing is often referred to as “Happy path testing”. It is 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 their own use. Positive testing uses only correct and valid data in test scenarios.

If a test scenario doesn’t require data, then positive testing would require running the test exactly how 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 the 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 the starting point, and B is the endpoint. There are two ways to go from A to B. Route 1 is the taken route and Route 2 is an alternative route. Therefore, in such a case, happy path testing would traverse 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 cases are the same. 

Negative Testing 

Negative testing is commonly referred to as error path testing or failure testing. This is 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 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 a serious impact on the consumption of the product on the whole, but it can also 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 write on paper.

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

• Change the medium that it is supposed to be written on, from paper to cloth or brick, and see if it should still be written.
• 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 stops 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 step, the user is expected to provide a name for the policy, as indicated 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 or special characters are allowed.
• The name can be a maximum of 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 the character limit).
2. abcdefgh (lower case validation within the character limit).
3. aabbccddmn (character limit validation).
4. aDBcefz (upper case combined with lower case validation within the character limit), 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), 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.

In both cases, you’ll notice a common pattern in the scenarios. Two parameters or techniques form the basis for designing enough 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 validating how the application behaves. Therefore, if you supply the inputs within the boundary values, they are considered positive testing, and inputs beyond the boundary values are considered 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. We assume that the various input data 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 positive testing, whereas invalid data classes will comprise negative testing.

In the same VLAN example above, you can divide the values into two partitions.

So the two partitions here would be:

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

In this article, we will learn how to classify positive and negative test scenarios. Let’s get started. 

Anything can be done either the easy way or the hard way. The important thing is that you do it. There are few simple everyday things, but without confidence, something about them does not quite fit in our minds and the extent of success is a hit or miss.

We will take one simple example today and find shortcuts that will not only clarify the concepts but also make sure that you will always get it right.

How to Classify Positive and Negative Test Scenarios

When writing test scenarios, we classify them into positive and negative conditions. (When you think about it, is it really important to make this classification? If yes, what purpose does it serve? We have to test them all anyway, isn’t it?) It beats me too, for the most part. I think it is an attempt to establish adequate coverage and help establish that we are testing both the happy and alternate paths the system is supposed to handle. Please write in the comments section below if you know of any other reasons why this is done.

Positive or Negative Classification of Test Scenarios/Cases

The test design process is 3 fold:

• Identify requirements
• Write test scenarios (one-line pointers of what to test)
• Design detailed instructions on how to test (test cases)

Now, let’s look at a few requirements, write test scenarios, and perform the classification.

#1) Login: A user who enters the correct credentials gets into the system. If the credentials are incorrect, access is denied, and an error message is displayed.

#2) View products: Let’s assume there is an online catalogue of all the products available in the system, and it displays them all in a list when the “View products” link is clicked.

#3) Logout: When clicked on this link, the user is logged out.

I am going to write a few test scenarios for these requirements.

Table A: The right way

However, sometimes I see a test scenario written like this.

Table B: Entries marked in red are invalid test scenarios.

For a login’s successful case, there is an equal and opposite case when it won’t be successful. Not all requirements are supposed to be that way, and for them, there is no compulsion to write a negative scenario.

Bottom line: Not every requirement should have negative cases.

At this point, if you are thinking “How will I know” or “I’m still not sure”, here is a simple cheat sheet that will help.

If there is one generalization we can make about applications is that they are dynamic. The input (data, clicks, etc.) that we provide will cause the application to be a certain way and generate a certain output.

A simple correlation between the input and output variables will make this easy to comprehend.

Let us try the following to log in:

As you can see from the above table, we can say that we categorize the primary flow as positive, and the alternate flow (also the correct behavior of the application) is marked as negative.

The last two cases in red are, in fact, bugs. Testing is about validation of requirements, and when they don’t work as intended, we find bugs. Since we are not validating for defects, the last two cases are invalid.

After following the same line of thought and applying it to log out and view products, here is what you will get.

As you can see, for these requirements, there isn’t a possibility of supplying an incorrect input. Therefore, there need not be negative test scenarios/cases written.

The system could be subjected to positive or negative input. Either way, the system should generate the correct output. The cases that tend to deal with correct input are positive. The ones that are about correct but negative input are negative.

In a nutshell:

#1) When end-to-end test cases are written for UAT or even system testing, it is always the positive test cases that make it into the flow.

#2) Sometimes, the classification is subjective. For example, if I am deleting something on a site and I receive a confirmation message that asks me “Are you sure you want to delete this entry?” with OK and Cancel options, according to me, clicking on cancel is a positive case. But some think, it’s negative as the primary intent of the “Delete” option is to delete and not cancel the operation. So, a tester’s judgement also plays a part in the classification.

#3) For every positive case, there isn’t always an equal and opposite negative case.

The above method always guarantees correct classification. Try it yourself and let me know if it does not. 🙂 “A shortcut is often a wrong cut.”- But then, it may not be in this case!

Conclusion

Many times, I have faced situations where people believe that negative testing is more or less a duplication of 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 to its usage by the customer.

Designing precise and powerful negative test scenarios requires the 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 repeatedly!

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