The T&D relationship

People who are into IT field are well aware of a very popular relationship; a tester-developer relationship. And presuming that people who are reading this article are into IT, let me not describe the relationship in details. Rather lets dive into why this blame game is perpetual and what can be done to reduce it, if cannot be eradicated fully.

A tester is supposed to judge the quality of the work done by a developer. Wait a minute, here lies the root cause of all discussion, all this sensibly nonsensical blame game or war would I say rather. I am a developer, I am intelligent and smart and geek and self-respected (does not being a developer itself prove that I have all these qualities? I bet this does). How heck is this that a tester (now guess being a tester proves what and what) will raise questions on my work; who literally could not have been written a part of the code that I have written in his whole lifetime. I am not going to accept whatever he’ll say. We have a word in English which expresses this feeling; yes you got it right. It’s EGO. And in this context it’s DEGO, a developers ego (you can forget the term DEGO, I have no intention to add more buzz words to the ongoing term-coining-competition). 

On the other hand testers have also an ego, a TEGO. Some might call it as blasphemy to say so as I belong to testing fraternity. But that is the truth. A tester’s ego hurts when he is seen as an inferior to the developers. And how would he retaliate? By reporting more and more issues and in that way he can prove his superiority over the developer. In a way it seems good as the number of defects found will increase. But the number of defects alone is not the synonym of good testing. The issues reported should be valid and the way it is reported is another important factor. A tester who is obsessed with the aim that he has to prove the developer inferior has very less time to focus on the quality of the issues he reports. And he ends up reporting whatever looks suspicious at one glance without rechecking it the second time. Sometimes we need to change the setting somewhere to see a correct result for an event. But we don’t do the settings work, get the incorrect behavior of the application and report it as a defect in one go and hence eat up a good amount of time of others rechecking it. And the level of bitterness in the relation rises up.

Now, what could be the possible solutions to curb the battle? Once we sort out the root cause of any problem, the solution is not miles away. Following things can come handy to maintain a healthy relationship among testers and developers.

To err is human: This is the reason why testing comes into picture. We make mistakes and this is what we do our best, don’t we? And it is very difficult for us to find out our own mistakes due to lack of objectivity. And we need some other person, a tester to check it. This is as simple as it. Testers are not employed to prove that whatever a developer has done, he has done it wrong. They just help a developer doing things correct. And at the end of the day when a product has relatively less issues and performs well, credit goes to developer, right? Then why not thinking that a tester brings credit to a developer by questioning his work and he is not an enemy, a friend rather. Just imagine what have happened if your parents had not judged every action of yours since childhood. If they had not taught you to discriminate between right and wrong. Would you have been here where you are now? And are your parents’ enemies of yours? They were constructive critics. So are the testers to the developers. And a critic is the father of a craft and the craftsman the mother.

Testing is a part of development: Many often make the mistake to segregate testing from development. They divide software engineering into two parts; software development and software testing. And hence they think testing as a redundant activity for a software development process. Many developers think that they can test their work and don’t need a tester. I have heard many developers saying they find more bugs in the system than their testers do. Here is where a tester loses respect.  In fact, testing is a part of software development. It provides information about the quality of the product and process. It helps producing a qualitative product and hence is equally important. The day developers start respecting testing and testers, we are in a better world I bet. Again developers, give it a thought!

If development (as they say) is primary, testing is not secondary: Many think that development (in reality, they mean programming or coding) should be our primary focus as it yields the product. Who cares about the quality? It’s a secondary thing and we’ll focus on it if time permits. And the irony is some organizations share this view. They underestimate testing and testers and boost the morale of the developers. They instigate them to feel how unwanted the testers are for them. But quality can never be compromised; at least you cannot afford to compromise it. Organizations/Managements, it’s worth of a thought, for your better sustainability!

Testers are bug-warriors, not developer-warriors: As mentioned above, when a developer underestimates a tester’s skill, the tester becomes ferocious and reports vague incidents. Incidents which are not worth investigating. But this not a way to prove the skill or retaliate. You can never leave quality apart if you want to show your skill, can you? If you really prove that you have skill, test the application rigorously, if something seems suspicious, recheck it twice or thrice. If it still persists report it. But report it in such a manner that it gives enough information about the defect and the way to reproduce it but yet being precise and succinct. It becomes easy for the developer to debug and fix the defect. Ease of work makes them happy. And happiness creates a healthy relationship. Testers, just a thought!

These as per me are the main reasons behind an unhealthy relationship between a testers and developers and these can be pretty much worked out to improvise the relation.

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.