Does a negative test pass when the application reports an error?

Only if that error and the resulting state match the expected behavior.

Is negative testing the same as security testing?

No. They can overlap, but invalid-input and exception-handling checks also address ordinary reliability.

Should all unexpected inputs be rejected?

Not necessarily. Some interfaces deliberately normalize or tolerate particular inputs; the contract determines the expected response.

AI Glossary / Data science and analytics / Beginner

Negative testing

Definition

Negative testing checks how software behaves when it receives invalid inputs or encounters conditions outside its intended normal use. The aim is to verify that the system rejects, handles, or recovers from those situations according to its requirements. A successful negative test often observes an expected error or refusal, rather than a normal successful transaction. The term does not mean that the test itself should fail.

What it means

Positive tests check supported behavior, such as submitting a valid order. Negative tests explore situations such as missing required information, an unsupported value, or an operation attempted in the wrong state. The important question is whether the response is correct and controlled. Merely causing an application to crash does not make a test successful, unless a very specific requirement genuinely calls for termination and the test checks that behavior.

How it works

Start from an interface contract or requirement that defines valid inputs and expected handling of invalid conditions. Select representative invalid cases and boundaries, prepare the required system state, and execute the operation in an appropriate test environment. Check the response and relevant side effects, such as whether records were created or changed. A test oracle specifies what counts as correct behavior. Error messages, status codes, exception types, recovery, and data integrity may all matter, depending on the interface.

Three practical examples

Form validation: a test submits a missing required field and checks that the form identifies the problem without creating an incomplete record.
Data import: an importer receives a malformed date and follows its documented rejection or error-reporting policy instead of silently guessing a value.
Service integration: a client sends an unsupported parameter and verifies the expected error response and absence of unintended state changes.

Think of it this way

Think of checking whether a gate stays closed when presented with the wrong ticket. The expected result is a controlled refusal with an understandable explanation. The analogy has limits: software may need to preserve data, release resources, or recover from partial work in ways that a simple gate does not.

Worked example

Suppose an order interface accepts an integer quantity from 1 through 100 inclusive. The requirement says invalid quantities must produce a validation error and create no order. Valid boundary checks include quantities 1 and 100. Negative cases include 0, 101, minus 3, the decimal 2.5, a missing value, and the text word five. For each negative case, the test checks both the documented error response and that the order count has not increased.
Imagine the 101 case returns the correct error message but still creates an order with quantity 100. The negative test should fail because the system silently changed and stored an invalid request, violating the stated requirement. Conversely, returning the expected validation error with no order created is a passing test, even though the requested business operation was rejected. If the interface intentionally allows numeric strings such as the text value 5, that case must be classified using the actual contract rather than a tester's assumption.

Illustrative case study

In a fictional reporting tool, a file upload with an invalid date produces a clear error, but half of the rows have already been imported. The specification requires the entire file to be rejected when any row is invalid. Testers add a check of the stored records and discover the partial update. Developers align the import behavior with the documented transaction policy. The case illustrates why visible error handling and underlying state must be evaluated together.

Common misconceptions and mistakes

Negative testing is not random input generation without expected outcomes. Fuzzing can help discover unusual inputs, but a test still needs a way to identify problematic behavior. Negative tests do not replace valid-use tests. A system that rejects every request would pass poorly designed refusal checks while being unusable. Error responses can also disclose unnecessary information or leave inconsistent state, so checking only that an error occurred is often insufficient. The relevant cases depend on actual requirements and risks.

Business use

Use negative testing where invalid data or unexpected states could disrupt a workflow or undermine trust. Prioritize boundaries, missing values, incompatible types, and invalid state transitions that users or integrations are likely to encounter. Specify whether the system rejects, repairs, skips, or rolls back problematic input. Make tests repeatable and inspect meaningful side effects. For AI-enabled applications, include invalid tool arguments or malformed structured outputs, while treating factual model accuracy as a separate evaluation problem.

Check your understanding

Why should the quantity-101 test fail if the interface displays an error but creates an order for 100 units?

Answer: The requirement forbids order creation for invalid quantities. Correct-looking feedback does not excuse an unintended stored transaction.

Related terms

Positive testing
input validation
boundary value analysis
exception handling
test oracle
robustness testing
fuzz testing
transaction rollback
error handling

Learn next

Choose one simple interface and write its valid-input contract. List valid boundaries and representative invalid cases. For each case, define the expected response and permitted state changes, then check that the tests would detect both silent acceptance and excessive rejection.

Sources

Microsoft, expected failures in SQL Server unit tests: https://learn.microsoft.com/sql/ssdt/using-test-conditions-in-sql-server-unit-tests Microsoft, testing a class library and invalid inputs: https://learn.microsoft.com/en-us/dotnet/core/tutorials/test-class-library ISTQB member board, historical testing glossary including negative testing: https://astqb.org/assets/documents/ISTQB_glossary_of_testing_terms_2.3.pdf

Previous: Negative sampling Next: Negatively skewed