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.
No comments:
Post a Comment