Positive Testing and Negative Testing with Examples
Thomas Hamilton
⚡ Smart Summary
Positive and Negative Testing together decide whether software accepts what it should and rejects what it should not. This article explains both approaches, the techniques behind them, practical examples, and the practices that keep defect leakage low.
Software testing is the process of verifying and validating a software application to check whether it is working as expected. The intent is to find defects and improve product quality. There are two ways to test software, namely Positive Testing and Negative Testing.
The two approaches answer opposite questions: does the application work when everything goes right, and does it stay stable when something goes wrong?
What is Positive Testing?
Positive Testing is a type of testing which is performed on a software application by providing the valid data sets as an input. It checks whether the software application behaves as expected with positive inputs or not.
Positive testing is performed in order to check whether the software application does exactly what it is expected to do. It is therefore also called happy path testing.
For example, consider the numeric text box shown below.
.png)
There is a text box in an application which can accept only numbers. Entering values up to 99999 will be acceptable by the system and any other values apart from this should not be acceptable. To do positive testing, set the valid input values from 0 to 99999 and check whether the system is accepting the values.
What is Negative Testing?
Negative Testing is a testing method performed on the software application by providing invalid or improper data sets as input. It checks whether the software application behaves as expected with the negative or unwanted user inputs.
The purpose of negative testing is to ensure that the software application does not crash and remains stable with invalid data inputs. It is therefore also called error path testing or failure testing.
For example, consider the same field receiving characters instead of digits.
.png)
Negative testing can be performed by entering characters A to Z or from a to z. Either software system should not accept the values or else it should throw an error message for these invalid data inputs.
In both types of testing, the following needs to be considered:
- Input data
- An action which needs to be performed
- Output Result
Positive Testing vs Negative Testing: Key Differences
Both approaches share the same test case structure. The difference lies in the input you supply and in what a passing result proves.
| Parameter | Positive Testing | Negative Testing |
|---|---|---|
| Also known as | Happy path testing | Error path or failure testing |
| Input used | Valid, expected data | Invalid, extreme or unexpected data |
| Goal | Confirm the feature does what it should | Confirm the feature refuses what it should not |
| Expected outcome | The flow completes successfully | A clear error appears and the system stays stable |
| Error handling | Not the focus | The entire focus |
| Coverage | Narrow, follows the specification | Broad, explores everything outside the specification |
| Typical risk if skipped | Core features ship broken | Crashes and security holes reach production |
A failing positive test signals broken functionality. A failing negative test signals a missing guard, which is far more expensive to repair once users have found it.
Testing Techniques Used for Positive and Negative Testing
In practice, two classic input-design techniques generate both positive and negative cases from the same requirement:
- Boundary Value Analysis
- Equivalence Partitioning
Boundary Value Analysis
This is one of the software testing technique in which the test cases are designed to include values at the boundary. If the input data is used within the boundary value limits, then it is said to be Positive Testing. If the input data is picked outside the boundary value limits, then it is said to be Negative Testing.
For example, look at the accepted range illustrated below.
.png)
A system can accept the numbers from 0 to 10 numeric values. All other numbers are invalid values. Under this technique, boundary values -1,0,1 and 9,10,11 will be tested.
Equivalence Partitioning
This is a software testing technique which divides the input data into many partitions. Values from each partition must be tested at least once. Partitions with valid values are used for Positive Testing. While partitions with invalid values are used for negative testing.
For example, study the two partitions shown below.
.png)
Numeric values Zero to ten can be divided into two (or three) partitions. In our case, we have two partitions -10 to -1 and 0 to 10. Sample values (5 and -5) can be taken from each part to test the scenarios. See the equivalence partitioning and boundary value analysis lesson for more worked examples.
How to Perform Positive and Negative Testing
The following sequence turns one requirement into a balanced set of positive and negative cases.
- Read the requirement for limits. Note every accepted format, range, and mandatory field. Whatever the specification allows becomes a positive case, and whatever it excludes becomes a negative one.
- Write the positive case first. Supply valid data, perform the action, and record the expected success result as the baseline.
- Derive negative cases from the same limits. Use boundary value analysis and equivalence partitioning to produce blank fields, wrong data types, and out-of-range numbers.
- Add hostile input. Include SQL injection strings, expired tokens, and malformed API payloads so security testing gaps surface early.
- Extend to non-functional checks. A load test at the supported user count is positive, while a stress test beyond that limit is the matching negative case.
- Choose where each case runs. Keep negative cases out of smoke and sanity testing, which are fast positive gates, and run them in functional and regression testing cycles.
An ATM withdrawal shows the pairing. The positive case enters a correct PIN and a valid amount, so cash and a receipt follow. The negative case enters a wrong PIN and expects a refusal message, then a card block.
Best Practices to Keep the Balance Right
- Write at least two cases per requirement, one positive and one negative, before development starts.
- Prioritise negative cases by impact, so injection and payment failures come before cosmetic input errors.
- Assert the error message itself, not only that the action failed, because vague messages are defects too.
- Leave room for exploratory testing, and log findings through your defect management process.
⚠️ Warning: Never run negative cases against a live production environment. They exist to force failures, and a deliberate crash affects real users and real data.
