1

What Is Negative Testing And How To Write Negative

Test Cases?
Having the most optimal product quality is the primary goal of the 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
consuming 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 craft
or design the test scenarios to make sure the particular application or product performs
the way it is supposed to.

While it is definitely important to verify that the software performs its basic functions as
intended, it is equally or more important to verify that the software is able to gracefully
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 several types 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 sections whereby we discuss what positive and negative
testing is, how they’re different and we’ll describe some examples to understand what
kind of negative tests can be performed while testing an application.
What You Will Learn: [show]

What is Positive testing and Negative testing?

Positive testing 
Positive testing, many times referred to as “Happy path testing” is generally the first form
of testing that a tester would perform on an application. It is the process of running test
scenarios that an end user would run for his use. Hence as implied, positive testing
entails running a test scenario with only correct and valid data. If a test scenario doesn’t
need data, then positive testing would require running the test 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 kind of positive testing. In alternate path
testing, the test is again performed to meet its requirements but using the 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: 
2

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 result in both the cases is the same. 
Negative testing 
Negative testing commonly referred to as error path testing or failure testing 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, or handling a bad value more
gracefully.
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:
Say for example you need to write negative test cases about a pen. The basic motive of
the pen is to be able to write on paper.

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 verify 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:
3

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:
4

Let’s establish some ground rules here 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 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 the cases above, there are two basic parameters or techniques that
formed a basis for designing sufficient amount of positive and negative test cases.

The two parameters are:

 Boundary value analysis
 Equivalence partitioning
Boundary Value Analysis:
As the name itself implies, boundary indicates limits to something. Hence this involves
designing test scenarios that only focus on the boundary values and validate how the
application behaves. Therefore if the inputs are supplied within the boundary values then
it is considered to be positive testing and inputs beyond the boundary values is
considered to be a part of negative testing.
5

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 is 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
6

Several 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 stand 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!