Negative testing

Negative Testing: The Forgotten Process

Does any company produce perfect code and applications? No.

Therefore, we test the application(s) and focus heavily on validating the requirements, as shown in the diagram below to the left.

However, one area that is not talked about is Negative Testing. This could be because of the name, as Negative Testing can be seen as a waste of time or effort.

“Why are you testing how an application fails when you should be testing that the functionality works?”

This is consistently the call from PM’s/ BA’s and stakeholders. No one likes to talk about failures or negatives.

In this day and age when usability is king, it only takes a couple of posts on social media to either make or destroy company’s reputation depending on the user experience.

Negative testing realises that applications may crash or shutdown.

In these circumstances, we want them to crash cleanly with a useful error message to the end user, as shown in the image below to the right.

Alternatively, if you were in the process of entering a significant amount of data when the system crashed, then upon restarting the application some, or all, of the data you previously entered is retained and repopulated so you don’t have to start from scratch, unless it was sensitive information which you don’t want repopulated.

What we don’t want to see.

As a rule, for every positive test you create on an application you should have at least two or three negative tests accompanying it. Embrace the fact that applications will fail as nothing is perfect in this fast world we live in. But ensure that when they do fail the user experience softens the blow.