Pages

Wednesday, March 2, 2011

Nature of job I am into: Perceptions of mine, other’s1 and other’s2


It’s been quite a long I was thinking of this article. Since I call this blog a testing blog, the job I am into is certainly testing. But what does nature of testing mean here? And moreover, what are other’s1 and other’s2? To simplify it, it is the nature of the testing job i.e. testing’s what and how about. Other’s1 here is the group of people who support my thoughts and views or it would be better to say that I follow their principles of testing and hence most of my perceptions, if not all would implicitly convey theirs. Other’s2, on the other hand are group of people who carry different perceptions from I do and I call their perceptions as misconceptions and I have reasons to call so. Surprisingly some of the testers fall on this group. I’ll discuss about them.
The key insight of this article would be addressing the myth that Testing is just another easiest job in the world. This perception about testing is ubiquitous. Everybody believes that anyone can do the testing job. They give reasons that they think support this myth. I’ll put their perceptions as MythX and my perception as FactX. So let’s go to the battle of Myth vs. Fact.

Myth1: Simple graduates (hence anyone) can do testing but not development: Why simple graduates are being hired for testing and not for coding or development (I swear I don’t know why they refer to simple graduates, don’t they have any dignity?). Because testing is easier than development and anyone can do this job if trained, or sometime they don’t need to be. Development is quite a difficult task and it needs geeks and genies.

Fact1: Every job in the world is just another easiest job provided you are passionate enough to doing that. Piloting a plane can’t be an easy job for all because Jessica Cox could do that without having arms. She could do that because she had passion. Simple graduates are hired because testing needs skill and to have skill you don’t need any technical qualification. James Bach is a high school dropout and still he is one of the best in testing community. Now would you say that if James Bach can be a good tester, everyone next door can be one? I would say yes but they have to have what James has, passion to test!  And I bet everyone next door can be an excellent programmer/developer, whatever you love to call it if they have passion doing that.

Myth2: If someone can’t do development, put him into testing and he’ll manage to do a decent job: I have heard that some company pull resources from development and put them into testing because they were inefficient at their work. How heck is this if it is true. And the irony is they call it degradation. They believe that inefficient people can’t make a quality product but they can judge the quality of that product.
 
Fact2: Probably we are very good at judging other’s works if at all we are unable to do that, ain’t we? This is why we suggest Sachin Tendulkar about how he should have played a shot sitting in front of television even if Henery Olonga would get us out every time he bowls to us. Probably from here we draw the conclusion that people who can’t make a quality product, they can easily judge the quality. Now for organizations who believe they did a great job by putting inefficient resources into testing, I would say they don’t really mean quality. If you don’t respect quality agents, you are simply not achieving quality. I would like to wish them luck for their future endeavors, if at all they have any future! And I would recommend them Moolya, the tester’s heaven if they can learn from them anything on quality.

Myth3: A tester can get involved in many projects, a developer can’t: There are instances where a single tester is assigned to more than one projects and he manages to work simultaneously. Developers are dedicated to single project. This proves testing is easier than development.

Fact3: I don’t say assigning a tester to more than one projects is bad. It is not only when the process is not hampered due to lack of time and obsession and compulsion due to many projects at a time. But there is no reason why the process wouldn’t be hampered. If any organization is following this, they are not serious about the quality. They are compromising quality. What I believe why they give more emphasis to development than testing is, development is the process where the product is made. “What the customer wants” becomes more important than “How the customer wants” for them. They think if they can deliver what customer wants, they can convince how they wanted it, who sees it after all? In a way, they are simply cheating the customers.

There are many other myths and facts but it will increase the length of this post and there was a chance of you not reaching the point you are reading now, but I am happy with the contents of this post for at least you find it worth reading till this point.

Let me announce that I didn’t want to prove any superiority of testing over development. Both of them are easy and yet difficult, only the perception differs.

Oh yes, I said that some of the testers fall in the other’s2 group. Really they do. And the reason is they take the myths seriously and are ignorant about the facts. Another reason is they dreamt of becoming developer but they were put (yes, you read it right PUT) into testing and they can’t fight for their dreams because they know they are not capable of winning it. And if you ask a simple yet vital question to such kind of testers “why testing is needed by testers?” answer like “it is because developers have not enough time to test it” is obvious. Pity that you have not given a chance to follow your dream, but the thought that you are contaminating the testing community being here is what kills me. Escape as soon as possible.

1 comment:

Sudhansu said...

Actually if someone read this blog he will not find any difference between tester and developer rather he will get some idea about what are the actual area of tester and developer . All are lions at their own work areas