The core aim of software testing departments is to attain optimal product quality.
By implementing an effective quality assurance process, testing units endeavor to discover the greatest number of errors during the testing phase, thus ensuring that the customer or end user does not experience any unusual behavior while using the product within their computing environment.
Recommended IPTV Service Providers
- IPTVGREAT – Rating 4.8/5 ( 600+ Reviews )
- IPTVRESALE – Rating 5/5 ( 200+ Reviews )
- IPTVGANG – Rating 4.7/5 ( 1200+ Reviews )
- IPTVUNLOCK – Rating 5/5 ( 65 Reviews )
- IPTVFOLLOW -Rating 5/5 ( 48 Reviews )
- IPTVTOPS – Rating 5/5 ( 43 Reviews )
Since pinpointing defects lies at the heart of a tester’s role, they need to meticulously craft test situations to verify that the system or product behaves as expected.
Verifying the proper functioning of a software product is crucial, but it’s also necessary to ensure that the software can manage abnormal situations smoothly. Many software bugs emerge from the creation of such situations by testers who employ both reasonable and acceptable creativity.
Most people are already well-acquainted with different kinds of testing, like operational testing, sanity testing, smoke testing, integration testing, regression testing, alpha and beta testing, usability testing, and so on. However, no matter the type of testing, it’s widely recognized that all testing attempts can broadly be classified into positive testing paths and negative testing paths.
In the following sections, we will delve into the distinct aspects of positive and negative testing, highlighting their differences, and presenting examples for a clearer understanding of the type of negative tests that can be conducted while assessing an application.
Covered in This Article:
Clarifying Positive testing and Negative testing
Positive testing
Positive testing, often known as “happy path testing,” is usually the first variety of testing executed on a system. It consists of running test scenarios that imitate user behavior. Thus, positive testing involves executing test situations with only correct and valid data. If a test scenario doesn’t involve data input, positive testing implies running the test as planned to ensure the system adheres to the particular requirements.
Occasionally, there may be multiple avenues to execute a specific function or task to furnish the end user with added flexibility or to uphold overall product consistency. This is called alternative path testing, which is another variety of positive testing. In alternative path testing, the test scenario is completed using a route different from the one commonly used, but still results in the same outcome.
The diagram below exemplifies this:
A signifies the starting point, and B represents the endpoint. There are two paths from A to B. Path 1 is the most often used, while Path 2 is an alternative path. Hence, in this instance, positive testing involves moving from point A to B using Path 1, whereas alternative path testing requires taking Path 2 from A to B. The result is the same in both scenarios.
Negative testing
Negative testing, frequently referred to as erroneous path testing or failure testing, is typically conducted to assess the application’s resiliency.
Negative testing entails maximizing creativity to validate the application against invalid data. The goal is to determine whether errors are appropriately reported to the user and to evaluate how proficiently the application manages incorrect or inappropriate input values.
Comprehending the rationale behind performing negative testing is key.
Effectively formulated negative scenarios are vital for measuring the functional reliability of software or an application. Negative testing not only aids in uncovering potential defects that could negatively impact the product’s usage, but it also uncovers situations where the application could crash. Ultimately, negative testing ensures that the software incorporates sufficient error validation.
Example:
Let’s say you’re tasked with forming negative test cases for a pen, whose main use is to write on paper.
Potential negative tests could involve:
- Trying to use the pen on a surface other than paper, like cloth or a stone, and verifying whether it writes.
- Dipping the pen in a liquid and checking whether it can still write.
- Switching the pen’s ink cartridge with an empty one and confirming whether it’s incapable of writing.
Real-World Examples of Positive and Negative Testing
Consider the instance of a user interface (UI) wizard for generating policies. In the wizard, the user enters textual values in one pane and numerical values in another.
First pane:
In the first pane, the user is required to input a name for the policy, as displayed below:
Let’s define a few rules to guide the formulation of positive and negative cases.
Specifications:
- The name textbox is a compulsory field.
- The description slot is not required.
- The name field should only contain alphabetical characters (a-z and A-Z). No numbers or special characters are permitted.
- The name field can accommodate a maximum of 10 characters.
Now, we can design positive and negative test cases for this example.
Positive test cases: Following are a few positive testing situations related to this specific pane.
- ABCDEFGH (valid uppercase characters and within the character limit)
- abcdefgh (valid lowercase characters and within the character limit)
- aabbccddmn (valid characters exactly meeting the character limit)
- aDBcefz (a combination of valid uppercase and lowercase characters and within the character limit)
- .. and the list goes on.
Negative test cases: Here are a few negative testing scenarios related to this specific pane.
- ABCDEFGHJKIOOOOOKIsns (name exceeding the 10 character limit)
- abcd1234 (name containing numeric values)
- No name entered
- sndddwwww_ (name containing special characters)
- .. and several others.
Second pane:
In the second pane, the user should solely input numeric values, as shown below:
Let’s assign a few rules for this pane as well:
Requirements:
- The ID must be a number that falls between 1 and 250.
- The ID field is mandatory.
These are some positive and negative testing scenarios for this particular pane.
Positive test scenarios: Below are a few positive testing situations for this specific pane.
- 12 (entering a valid number within the stipulated range)
- 1,250 (entering the extreme values of the specific range)
Negative test scenarios: Below are a few negative testing situations for this specific pane.
- Ab (inputting alphabetic characters instead of numbers)
- 0, 252 (inputting numbers that fall outside the prescribed range)
- Empty input
- -2 (entering a number outside the given range)
- +56 (inputting a valid number preceded by a special character)
Core Factors Aiding in Creating Positive and Negative Tests
Upon closely analyzing the examples given above, it’s evident that there can be several positive and negative scenarios. However, the key to effective testing is optimizing a comprehensive list of positive and negative scenarios to ensure comprehensive testing coverage.
In all the cases, you will detect a recurring pattern in the design of scenarios. In all cases, two primary elements or techniques establish a foundation for devising an ample number of positive and negative test cases.
The two elements are:
Boundary Value Analysis:
As implied by its name, boundary value analysis is centered on the boundaries of something. It involves the creation of test cases that primarily target the boundary values to confirm the application’s behavior. Thus, if inputs are within the defined boundary values, it’s viewed as positive testing, while inputs exceeding the boundary values are recognized as negative testing.
For instance, if an application accepts VLAN IDs that range from 0 to 255, the boundary values are 0 and 255. Any inputs below 0 or above 255 would be deemed invalid and hence constitute negative testing.
Equivalence Partitioning:
In equivalence partitioning, test data is divided into separate partitions or equivalence classes. The hypothesis is that input data within each partition behave the same way. Hence, it’s sufficient to test just one specific condition or scenario from each partition. If that condition works, all the others in that partition are presumed to work as well. Similarly, if one condition in a partition doesn’t work, it can be speculated that none of the others in that partition will function.
Therefore, valid data classes within the partitions represent positive testing, while invalid data classes represent negative testing.
In the VLAN example mentioned earlier, the values can be divided into two partitions.
Here are the two partitions:
- Values ranging from -255 to -1 in one partition
- Values ranging from 0 to 255 in another partition
Final Thoughts
Many perceive negative testing to be merely a replication of positive testing, failing to recognize its essential role in supplementing positive testing. As a tester, I consistently promote the inclusion of negative testing as a fundamental component of the quality assurance process for those who comprehend and aim for superior quality standards.
Although positive testing affirms the business use case, negative testing guarantees that the delivered software is devoid of defects that could hinder its usage by clients.
Designing accurate and robust negative test situations calls for innovation, foresight, skill, and intelligence on the tester’s part. Such skills can be developed over time, so keep growing and evaluating your full potential!
About The Writer: This guest post was written by Sneha Nadig, who has more than 7 years of professional experience as a Test Lead in both manual and automated testing projects.
We welcome your thoughts and experiences related to negative testing.