Negative Testing

Any provocation of application failure is designed to surface in the test rather than once the application is approved for production. An optimal response for an application to a negative test is to gracefully reject the unexpected or invalid data without crashing. While exceptions and error conditions are expected in negative tests, they are not expected in positive tests. It is optimal to combine a range of positive and negative tests to run on an application for thorough examination of behavior.

Negative testing is aimed at detecting possible application crashes in different situations. It should not be confused with misuse case testing. Systems are often built with negative requirements, which require that certain functions cannot be attempted unless certain conditions are met. Traditionally, negative testing was focused on these negative requirements.

Safety-critical systems tend to blur the line between negative testing and misuse case testing, since their demand for ultra-high reliability and fail-safe operation or controlled shutdown forces requirements analysts and design engineers to build the system with such "out of limits" conditions in mind.

Strictly from an information security perspective, this line may be blurring as well. Negative testing implies the need for the requirements analysis process to thoroughly identify such negative conditions; attackers, however, tend not to be constrained by their target's requirements analysis.

Advancements in automated testing, such as fuzz testing, make it much simpler for systems owners and attackers alike to run tens of thousands of test cases at the edges of the operationally acceptable systems envelope and well beyond it. Both sets of testers are seeking to find vulnerabilities, but have different agendas, of course.