Guidelines for Negative Test Cases

While it is important to verify that the software performs its basic functions as intended, it is also equally important to verify that the software 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, whereby we discuss what positive and negative testing are 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 

“Happy path testing” is another term for positive testing. It is the initial type of testing that an application would undergo. In this method, test scenarios are conducted as they would be used by an end user. Only accurate and legitimate data are used in test scenarios for positive testing.

Positive testing would entail conducting the test precisely as intended in order to verify that the application is fulfilling the requirements, especially if the test scenario doesn’t call for data.

There may occasionally be multiple approaches to carrying out a certain operation or function with the goal of providing the end user greater flexibility or ensuring overall product consistency. Alternate path testing, which is another name for this, is 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 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 the 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.

Only with well-crafted negative situations can the functional reliability of the program or application be measured. Negative testing can be helpful in identifying the circumstances in which an application may crash in addition to highlighting any potential defects that might have a significant effect on the overall use of the product.

Lastly, it guarantees that the software has adequate error validation.

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

There can be a variety of both positive and negative outcomes if you pay close attention to the examples above. Effective testing, on the other hand, is the process of optimizing an infinite number of both positive and negative scenarios so that adequate testing is accomplished.

You’ll observe a similar pattern in both situations. The foundation for creating sufficient positive and negative test cases consists of two parameters or approaches.

The two parameters are:

• Boundary value analysis
• Equivalence partitioning

Boundary Value Analysis:

Boundaries denote limits to something, as the name suggests. Therefore, this entails creating test scenarios that verify the behavior of the application and only concentrate on boundary values. As a result, inputs that fall inside the boundary values are regarded as positive testing, while those that fall outside of them are regarded as negative testing.

For instance, if a specific application is compatible with VLAN IDs between 0 and 255. Therefore, the boundary values in this case will be 0 and 255. Negative tests will result from any inputs that fall below 0 or rise over 255 since they will be deemed invalid.

Equivalence Partitioning:

The test data are divided into multiple partitions using equivalency partitioning. Equivalence data classes are the name given to these divisions. We presume that each partition’s different input data behaves in the same manner.

As a result, only one specific circumstance or condition from each partition needs to be evaluated because, if one does, the others in that partition are presumed to function. In a similar vein, none of the conditions in a partition will function if one of them does not.

As a result, it is now clear that positive testing will include legitimate data classes (in the partitions), whereas negative testing will include faulty data classes.

The values in the aforementioned VLAN example can be separated into two partitions.

So the two partitions here would be:

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

Conclusion

I have often seen situations where people believe that negative testing is simply a reiteration of positive testing, rather than acknowledging the reality that negative testing supports positive testing.

My stance on these matters as a tester has been constant. Those that understand and strive for high standards and quality will surely need negative testing in the quality process.

While positive testing ensures that the business use case is validated, negative testing ensures that the provided software is free of flaws that can deter the user from utilizing it.

To develop precise and powerful negative test scenarios, a tester must possess creativity, vision, talent, and intelligence. Most of these skills might persist and continue to evaluate your complete potential!

You May Be Interested In This Blog:-

Deep Entity in SAP OData Advanced Integration Explained