Staying Positive in Negative Testing

We (not that it's a secret) are pretty sensitive about our products’ quality and cautious about any system’s failings. Because each fail seems to justify the testers’ existence in the world. It even makes us feel like a bunch of heroes, you know: A great Tester came and saved his users from the terrible critical bugs!

Our testers never forget about negative testing, although not all the developers are happy about that. However, these checks are not about being the “maleficent testers”, they are essential for closing up the vulnerability issues and insuring against hacker and bot system penetrations along with the Dos / DDos attacks.

Of course, because what’s the each and every test specialist’s mission? To find problems. Those problems that no one has time to think of, doesn’t want to see them and deal with them. And if not only the correct operation of the system, but its abnormal behavior is on check too, then the in-team tension rises up high to the sky.

It makes sense, because the programmers develop software aiming at the result, at the planned launch, flying on the wings of inspiration! Then the stage of testing is coming with numerous fixes and “perfect” code alterations. Hide yourself people, the system is under test.

To stay out of conflicts, some testers may delay the negative testing for later or even ignore it (OMG!) in favor of shorting the timeline and budget. Sure, why check negatively if the program doesn't even operate in the prescribed way, right? Nope.

Positive and Negative Testing

But first things first. When testing the software using test cases, there are two sets of checks: positive and negative. Positive Testing is a system check on meeting its normal (standard, expected) behavior, according to specs and documentations. Here we are inspecting if the software performs obligatory tasks, if the solution complies with the actual requirements, if the UI guidelines are supported, etc.

Negative Testing is a system check on unintended behavior situations. For example, we examine if the software is stable to incorrect input data, how it handles exceptions, what information is displayed in error messages, if it’s possible to disrupt the product’s functioning and / or affect its performance and so on.

We have said that some specialists leave the negative testing for later or even forget about it, which is almost the same. You know, anything deferred for later almost always stays unperformed.

Therefore, in our opinion,

Negative and Positive testing should be combined, not separated in time and space.

Because can we say that the system works as it should if we only check its reaction to the correct input data?

Positive-negative Testing

Testing process needs some extra skills like intuition, hunting instincts, sixth sense – call it whatever you prefer. And here’s our tester checking the registration form, for example.

He tests the product consistent with the specs and test scenarios, inspects how the user-entered data is processed (it is not necessarily the case that user will enter the data, FYI), and then that's it – the flash! He feels that if right now, in this second, he’ll type in this login field some “%oneonelol% />” instead of the plain text, then something is definitely going to happen. Something dark and gloomy wrong.

So what? He must say to himself, “No. Now it’s time for the positive tests and nothing else. I have my negative checks planned for the next week, so then I’ll put my “%oneonelol% />” idea in action. Probably”?

We believe this approach to negative testing to be ineffective, and here's why:

• If you carry out the positive and negative tests individually, it will take more time. At least because it will already be two separate iterations of testing.
• Testers and coders live under deadlines. And if the time is strictly limited, laying the negative testing aside increases the risk that it would be left behind and forgotten. After all, the closer to the point X, the faster time flies; and the team still should perform all the tasks required, correct defects, and apply the final business requirements (which might be changed). Deadline season is hot!
• Separation of negative and positive testing, in our opinion, simply conflicts with the tester’s nature! After all, his main task is to check the system for all possible end user actions. And people are mostly illogical, so they might surprise the software with a variety of mind tricks ;)

We, as testers, are very worried if the system contains the negative category errors. And especially if the consequences of such bugs are critical to the entire system. But we are brave enough to report them. Especially with such a joker in a sleeve – we have a bunch of girls in our testing team. And who will stubbornly defend the “perfect” code when their gentle cute voices beat the project's integrity all to pieces? That's right.

Let’s Connect the Final Dots

Don’t forget about the negative testing, combine it with the positive one, assemble a team of experienced professionals and try to shift the reporting task on girls! All, except the last one, we recommend on 100%, and the last we'll leave on your project manager's shoulders.

And be sure to check your product, don’t think that programmers write clean and beautiful code at one blow – you can't go without bugs anyway! Not to mention the numerous vulnerabilities in software, which is perfectly confirmed by the personal and confidential data regularly leaking online.