Monday, January 11, 2010

QA - are they required anymore???

Agar hum nahi honge to tumhara kaam hi kya hai company me…..
Tumhe req to samajh nahi aati bas aise apna bug count badane k liye bugs daalte rahte ho……
Tumhe coding nahi aati…. Firr IT me kya kar rahe ho….

These dialogues can be heard in any of the IT company (obviously from devs only).
Often the tester is seen as the anti-developer, with the developer standing for creation and the tester the destroyer of the developers work. On many occasions you will see their two departments almost fighting battles as each tries to prove its worth and capability.

According to one of my colleague the developer and their skill set are valued above the tester. Within the project life-cycle, development is considered essential, testing as a “nice to have” but not mandatory. Initially I differ from her but unfortunately, sometimes I feel the perception of testing as a inferior role in some developers mind.

When code goes live and the volume of bugs is minimal with positive user experience, it is rarely the tester that is thanked for their diligence: more likely to be the developer thanked for their fantastic software. And on the other side if client has reported bugs in software then the whole blame goes to tester.

The developers mind set is one of creation whereas the tester is one of destruction. There is no doubt that the tester becomes redundant if there is no development whereas the opposite is not true. Many projects still run today with no focus on testing and the burden is placed on the users to experience the problems and report them.

I almost fought with one of my senior when I heard him saying “I would recommend that the "not-so-hot developers should be made full-time testers”. Many of the same skills and tactics that make a developer successful also make a tester successful. How can he be so sure that bad developer will be a good tester? If you value quality a lot, then you may should the specialized skills and tactics that a tester brings to the project, since that's what testers specialize in.
Imagine a scenario: Organization doesn't value testing because they have a low opinion of testers and think developers can do it better. Organization, have communication issues or personality issues, whatever.... Organization notices that they are decides to take a chance. It allocates some developers to be testers. Those developer-now-tester's struggle in their new role for all the same reasons they struggled with their old role (they don't read, are slow to learn or adapt not getting increased value from adding testers.) This lowers their opinion of testers even more. The call goes out for more developers to become testers to help stabilize the experiment. Now that the tester negative perception has been "confirmed", even worse candidates are sent over to become testers. If external candidates are hired, they are hired by developer-now-tester's who don't know what a good tester looks like - so they hire those like themselves. Those developer-now-tester's struggle even more in their role.. organization notices that they are getting no increased value from adding testers. This lowers their opinion of testers even more. The experiment is over. They gave it a shot, it didn't work out. Their earlier assumptions that just having developers is "confirmed." They knew it all along anyway, right?
Perhaps the above case appears to be dramatic to you but it is not far from true.
This “anyone can do” attitude is followed in many IT companies and QA job is treated like plug n play(i.e.. anyone can perform)