In Rapid Software Testing, a “positive test” is one that honours every required and explicitly declared condition or factor for a desired outcome. A “negative test” is one that violates (or dishonours, disrespects, ignores, omits, undermines…) at least one required and explicitly declared condition.
That said, we don’t talk very much about positive and negative testing. We do talk about “sympathetic testing“, a closely related idea named by Cem Kaner. Sympathetic testing helps us to learn about the product and how people would obtain value from it. Rich models derived from that learning help us to focus on finding more important bugs.
“Positive testing” is really about demonstration or confirmation; showing that the product can work. It might be a good idea to situate a fair amount of positive testing in a suite of maintainable automated checks, to cover conditions in which people will do exactly what they’re supposed to do at just the right time.
That may be all right as far as it goes, but it doesn’t fit very well with the real world. In the real world, people make mistakes. They get confused, become curious, forget stuff, experience frustration, feel impatient, act mischievously… They do things that the product’s design does not anticipate or specify, and they do so accidentally, incidentally, inadvertently, inventively, desperately, obliviously, intentionally, maliciously,… They don’t follow “the rules”—which aren’t really rules at all; just someone’s hopes or desires that everyone will behave themselves.
People will violate at least one explicitly required condition a lot more often than you think. So, as testers, it’s crucial for us to challenge the product and vary our tests to find out how it responds.
Excellent testing isn’t limited to showing the the product can produce an expected result. Excellent testing includes learning what the product does when people do something unexpected.