A Reality Check to Software Testing

To justify the existence of software testing, one needs to point out some aspects that constitute it.

First, you have the tedious, repetitive bombardment of functional testing. Secondly, the application in question must be put under a considerable amount of stress, which will result in whether the application can handle a high load of data traffic and process it desirably. Last but not least, there is the creative task of replicating real life scenarios, which unless provided, might require some research effort.

When trying to replicate real life scenarios, as the name implies, I always try to be as human as possible. The use of any external testing tools, scripts or any other form of black magic would defeat the whole purpose.

On the contrary to stress testing, a person will not click on a single button for 100 consecutive times. Similarly, it’s physically impossible for a user to populate 250 fields with data in a few seconds. Although you would feel relieved knowing that the application can actually handle a task that only a super computer or Chuck Norris can perform, sometimes the scenarios can be a little far-fetched, although not always.

I was testing a medical application that was designed to run on a tablet PC. This would eventually be used by nurses and doctors alike to record test results while examining patients. Whether or not more than one nurse or doctor would be examining the same patient and using two tablets simultaneously wasn’t documented.

Hence, for the most part it was assumed by the team that only one nurse or doctor would be examining a patient at any point in time.

One hot summer afternoon, I was performing some end to end testing as the application was due to be presented to the client for the first run of UAT in a couple of days.

Suddenly, an idea popped into my head. Perhaps I should try and test the application by running more than one single instance simultaneously. Seems reasonable, no?

I shouldn’t have. All hell broke loose that day. I realized that since we had made a very foolish assumption, the system was not designed to handle this. Data was being lost and the application was crashing randomly. I turned to my fellow team mate developer with a sense of guilt or rather, fear. Fear of what might happen to my own wellbeing after I tell him what I had just discovered. Luckily, being a team stronger than the mighty Avengers, we knew exactly how to tackle this. We spent the next 12-hour days fixing and testing the system until we were confident enough.

The big day arrived. Everything was running smoothly and the client was quite impressed. In fact, they were so impressed that they even congratulated us for thinking ahead with respect to this particular scenario. Then, they said it wasn’t normal procedure to have more than one member of hospital staff examining a patient at any point in time, and that we could have discussed it in the second phase of the project.

Needless to say, my team and I felt like breaking down into tears, even if we did get through this looking like superheros and smelling of roses.

We just couldn’t believe our ears. With better communication all of this could have been avoided. 

Confessions of a Tester is written by Johnny, a test leader by profession and friend of ReQtest’s. Johnny loves clean code and is suspicious of anything that seems to be completely bug free. Apart from bug tracking at his day job, Johnny plays guitar, watches action and gangster movies and is a great fan of comic books and superheroes. This blog is a chronicle of Johnny’s Software Testing Nightmares.