Verifying that the program can effectively manage an unusual circumstance is just as crucial as confirming that it carries out its fundamental operations as planned. Most flaws are created by testers in imaginative scenarios.
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 move on to the following section, where we go over the definitions of positive and negative tests and their differences. To learn more about the types of negative tests that can be used when evaluating an application, let’s examine a few instances.
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 is another name for this kind of positive testing.
Alternate path testing involves rerunning the test to satisfy its requirements, but this time, a different path is taken than the obvious one. To get the same outcome, the test scenario would even use the same type of data.
It can be diagrammatically understood from a very generic example described below:
B is the destination, and A is the starting location. From point A to point B, there are two routes. Route 2 is an alternate route, and Route 1 is the one that is taken. Thus, in this scenario, happy path testing would use Route 1 to get from point A to point B, while alternative path testing would involve utilizing Route 2 to get from point A to point B. Observe that the results in both the cases are the same.Note that the outcomes in both situations are 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.
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 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.
- ABCDEFGH (upper case validation within the character limit).
- abcdefgh lower case validation within the character limit).
- aabbccddmn (character limit validation).
- 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.
- ABCDEFGHJKIOOOOOKIsns (name exceeding 10 characters)
- abcd1234 (name having numerical values)
- No name supplied
- 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.
- 12 (Entering a valid value between the range specified)
- 1,250 (Entering the boundary value of the range specified)
Negative test scenarios: Below are some negative testing scenarios for this particular pane.
- Ab (Entering text instead of numbers)
- 0, 252 (Entering out of boundary values)
- Null input
- -2 (Entering out of range values)
- +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
Rather than accepting the truth that negative testing supports positive testing, I have frequently encountered cases where people think that negative testing is essentially a repetition of positive testing.
As a tester, my position on these issues has never changed. Negative testing will undoubtedly be required in the quality process by those who recognize and aspire to high standards and quality.
Negative testing guarantees that the given software is free of defects that could discourage the customer from using it, whereas positive testing guarantees that the business use case is confirmed.
It takes the tester’s imagination, vision, talent, and intelligence to create accurate and potent negative test scenarios. The majority of these abilities may be learned via experience, so hang in there and keep assessing your full potential repeatedly!
YOU MAY BE INTERESTED IN
The Art of Software Testing: Beyond the Basics
Automation testing course in Pune
