Why do you need testers

A very, very common question by people who cannot understand why developers can’t find or prevent bugs in their own code. Maybe they are managers who haven’t been developers. Maybe they are developers who are finding it hard to admit that they can also make mistakes.

So, I was asked what I would do if I was told that the project would be taken live without testing, and that testing was not required.
I replied I would let them take it live without testing, and then let them face the music from the customers themselves. That would be the practical way. Because experience is the best teacher, and the best way to let someone know something’s importance is to let them have a lack of it.

No amount of debating can convince a person who has made up his mind that testing is not required. He has to be either forced into accepting it as a part of work life, or he has to be made to face the consequences of its lack to realise the importance.

But, if you need the theory behind why testing is required,  here’s why.

1. The most important point. There’s a difference between a developer’s attitude (creation), and a tester’s attitude (destruction).

A developer wants to show that the code is working. Because of this, he/she subconsciously selects such test inputs that have low probability of causing errors. It’s in the psychology, one cannot help it.

A tester wants to show that the code doesn’t work. Not that they are against it or anything. They just break it so that it can go all patched up, and smooth, into the customers hands.
Testers love to be the only ones who break it, so that the team doesn’t ever have to face a red-faced customer demanding they fix the issue that very moment. Errors can take days to resolve at times, but when the problem is at the customer’s end, every minute counts.

2. People say every thing was fine and smooth, even before the tester stepped in. Are you sure?
There was no tester before who would have told you that some very critical problems had been left hidden beneath the illusory smooth surface of the code. You know, developers are human, and they can make mistakes too. One needs to make sure that at least the severe mistakes don’t land in the hands of the customer.

Very few Customers tell you about the problems they face. Most of them just get irritated, try to work around, and stick to you only until a better service/software comes in the horizon. Then, suddenly, your user base just stops being yours, and shifts to your competitor who cared more about finding the quality issues and fixed them. (Wanna know more?)

3. Have you heard of the game ‘Chinese whisper’?
People sit around in a circle. One person whispers something into the neighbour’s ear, who whispers the message into the next person’s ear. The message is passed until it reaches back to the person who had started the chain. When the chain ends, the message always gets drastically twisted into something else.

Now, consider the learning from the game above into the software development cycle. When a software is developed, a number of teams and people are working together.  The requirements are passed on in a chain and might have passed through many levels until they finally reach the developer who will work on it. Imagine how distorted the requirements might have become till they reach the end of the chain.

The tester being in the process since the beginning (requirements phase) will be able to inform you about the misunderstanding of the requirements. Also, testers make it a point to understand the bigger picture and are at a better position to ascertain quality than the developer who has knowledge only about the part of the code he/she is working on.

4. The later the stage when the bug is found, the higher is the cost of fixing it.
As the bugs reported by a customer maybe vague due to their lack of knowledge about the code, it would be even harder and more time consuming for the developer to isolate the exact line of code that is causing the issue. And what worse experience than a customer shouting at the other end, while you’re desperately trying to find the cause of the elusive bug just reported to you, with immense pressure to resolve the bug immediately. You are at the brink of pulling your hair out because here you have not even understood where the problem is, and you are being asked to deliver a solution within an hour. You just want to stand up and shout curses in the air, just because the issue was not found earlier when you had an option to not deliver a software with such critical problems without solving them. If the bug had been found earlier, you would have worked with a calmer state of mind too, thus helping you to work faster.

5. Code might work perfectly fine as an individual unit, but might break when two separate units are integrated together.
You have website that works fine in itself. You have a backend portal that works perfectly fine in itself too. Maybe, the two softwares were made by two different teams who don’t have much idea about the other team’s software. Now, you integrate the two softwares through an API. But, things go wrong. Data collection gets wrong, and reports are incorrect, because they realised too late that the softwares had not been integrated properly. Maybe a variable was required to be passed but wasn’t due to some misunderstanding of specifications. Maybe the value passed was not the same as expected. And this integration error, that none of the teams could have found themselves without first taking weeks, or months, to go through the entire code of the other team, causes a huge loss in revenue.

But, if people, even after the practical/theoretical knowledge of the importance of testing, think they can do without testers in their team, I’m really curious to know what their game plan is to reach the #1 spot. Or if they are already #1, I’d like to know their game plan for maintaining their spot. Because, as far as I know, it’s just not possible.