"Some birds aren't meant to be caged, their feathers are just too bright"- Morgan Freeman, Shawshank Redemption. This blog is from one such bird who couldn't be caged by organizations who mandate scripted software testing. Pradeep Soundararajan welcomes you to this blog and wishes you a good time here and even otherwise.

Monday, February 19, 2007

Tester Developer Relations - A study based on Indian context

Programmers are vital resource of information to a tester!

If testers start looking at developers as vital resource of information, there is a lot better testing that can happen over that place. Rapid Software Testing says, "As a tester be a service and not an obstacle to the project" and isn't that amazing? One dimension to being an obstacle to the project is about having a bad relationship with developers.

The highlight

It is not just a tester-developer relationship that goes bad in an organization. Speaking from my experience, a developer-developer relationship has gone bad and a tester-tester relationship is no exception but the highlight of all is tester-developer. I infer from the results of a bad, developer-tester relationship that the resultant was more expensive than a developer-developer or tester-tester relationship going bad.

The ownership problem

It appears to me that if you ask a developer and a tester, a question of who contributed to the relationship going bad, a testers finger would point at the developer and the developer would be a victim of Newton's 3rd law. It is a rare occasion that a tester or a developer would point his finger at himself. Sometimes, the developer or a tester is not aware that management is also a reason behind it.

In India, I have heard so many stories of management being a major contributing factor to the developer-tester relationship going bad. I must admit that there are certain companies in India who encourage a tester developer relationship but I am not sure where they are.


Fear of university

I am happy of having done this detail research in which I explored the mindset of a tester when he works for a developer from a better university than where he graduated from. In India IIT and IISC are considered to be the most fundoo universities. Start ups, usually hire fresh graduates from IIT and IISC for development and conduct a walk in for testers and pay them 1/10 th of what an IIT Developer is paid. Some testers start feeling inferior and their confidence at the start of the career goes down. They turn out to look for development jobs.

Here is an interesting story: In one of the company I worked for, I was one tester for 3 developers who were from IIT and IISC. They welcomed me with a look as if , "Is this guy going to find bugs in my code? ha" and it took me little time to understand that they too were humans who could make mistakes. After a couple of months, the three developers from top universities called me, "Crash specialist" and I enjoyed a good relationship with them. There was another tester on a similar project in the same company working for 3 developers from premier organizations I mentioned. That tester always exhibited discomfort working with those three as he kept feeling inferior. He quit the company as he could not live with inferiority complex for a long time.

Now, I know the secret of killing inferiority complex when it is caused by someone who claims to be the best programmer on earth. As you are my blog reader, I want to share the secret with you but keep it within yourself. The secret is ...FIND BUGS IN HIS CODE!

Self assumed slave!

I am not sure why such an assumption enters a testers mind but I have seen some of my co-workers running to a developers seat when a developer calls the tester over his extension and say, "Can you come to my seat?". A self assumed slave tester runs towards a developers cubicle dropping the test he was doing and also without asking the reason for the developer calling him.

Here is another story: In one of the companies I worked for, I saw a tester who looked to my eyes as sitting idle and I *requested* him to join me for the test content generation so that I could get better ideas. I said, "Hey let's generate this file as a test input" and started doing it. The tester interrupted, "Pradeep, can I ask the developer and come whether we can test with this clip?". Jeez! why should he ask a developer whether we testers can use a clip for testing? On probing him, I got to know that he was once scolded by a developer for doing a test without informing him. That's funny!

Developerophobia

Most of the developers I have worked with never hesitate to ask for information from testers when they need it and I admire them for that. On a contrary some testers who were co-workers to me have feared to ask for information from the developers. This class of testers feel that developers might consider the questions as *silly*. What this class of tester is not aware is, questioning needs to be his tool to solve any testing problems he has in hand. If you aren't questioning, you aren't testing!

Finding bugs to bug a developer

Some testers are eager to find more bugs to keep the developer busy in case the relationship is in a bad state. Such a tester feels great after doing so and he doesn't realize that he isn't concentrating on learning a product while testing it. He keeps thinking, the crash and the hang that crashes a developers weekend plans.

Another dimension is, the severity and priority of the bug found is for no reason kept high by a tester to bug the developer and only a chain of mails flow to bring the levels down.

The foreign trip trauma

Some developers who come back from an on site assignment behave with testers in a way that makes the tester feel deprived of certain things. Are you thinking I would say, "This is a developers mistake?"
Nah! It is still a mistake of a tester who fails to recognize, being in India he is in a fastest growing economy of the world and the most watched nation of the world.


The jargon menace

Developers seem to talk jargons that a tester might not be aware of. Under some situations, a tester gets to feel inferior but the tester does not realize the fact that he need not know all the jargons the developer knows. A tester ideally should know a product better. In my experience, I worked with a developer who was writing code for an MP3 application whose jargons and lingo I did not understand but came up to me once, to ask in a soft voice; can I know how to do a Fast Forward in this application?.

Do you now think, I am trying to say a tester is better than a developer in this context?
Look at them, they do come out and admit mistakes/ask for information in front of a tester!

Testers need to realize that it is not just by talking and knowing the jargons of a developer helps him become a better tester but *skills* do make them better tester.

Development Managers heading Test team

Yeah! Wonderful point to end. Testers, in some companies report to a development manager. They never miss a chance to share their stories when they meet testers from other company, anywhere. The story is simple, the development manager is partial and developers get more hike and better appraisal each time. There is no end or beggining to such a story.

A story I heard: A tester went to the development manager and asked; why are you heading us?. The tester had to look out for a job, soon and the story ended there.

Think of Time v/s Value and Cost v/s Value , you might start doing more of testing! Enjoy solving better testing problems.


-- Pradeep Soundararajan - pradeep.srajan@gmail.com +91-98451-76817


"Pradeep's first language is not English--his first language appears to be testing." -- Michael Bolton

13 comments:

Pradeep Soundararajan said...

@Nattu

1. A tester who has phobia for learning programming, can he/she be successful as a tester?

Yes, he/she can be and it depends on what you mean by "success" of a tester. In my experience, non programmer testers have been excellent designer of a tool or script, forgive them they might not be able to code.

2. As a tester, don’t I need to learn the product from the eyes of the user and be able to explain the product need, product functionality?

As a tester, if you explore the program you might be able to do that. Also an important skill of a tester is to look the product from not just one user eyes but a whole lot of users, without forgetting the fact that the tester has eyes too.

3. Analytical ability, learn ability, testing skills are fundamental prerequisites. If I don’t have these, isn’t it going to lead me to a feeling of inferiority?

It might lead you to inferiority complex if you want to become good at testing. You might not feel inferior if you didn't intend to become a better tester but just a man on the job for money.

Mukesh said...

Hi Pradeep
once again you have touched very important topic. I am agree with you that management is also responsible upto certain extent for bad relationships between tester and developers.
The other thing I noticed is that if tester have some programming language then tester can have better impression.


Thanks
Mukesh

Pradeep Soundararajan said...

@ Mukesh,

The other thing I noticed is that if tester have some programming language then tester can have better impression.

You are right! But there are some non skill issue to getting bad relationship with developers.

You reminded me to tell this story - Once a tester to whom I met said, "I think I am a better developer than other developer in my team. I can find some silly programming mistakes".

I am convinced if that tester shows this expression or frustration to the developers there, relationship is at stake. However that tester has been handling it well so far, I guess. Not all testers might handle it smoothly.

Thanks for mentioning an important point. I saw your blog and I think you should start writing more.

Dinesh Karmankar said...

Nice Post Pradeep...I think its applicable to Tester Developer relationship globally :-)

Pradeep Soundararajan said...

@Dinesh,

Thanks for liking the post.

I think its applicable to Tester Developer relationship globally.

NO! As testers we must realize the fact that we all live in different contexts.

For example, Debasis put up a comment saying - "I can tell you from my experience that he is far from being *partial*." - which I did not approve.

What he means by that is his manager is far from being partial and not all since he hasn't worked with all managers to know that.

I have collected samples of the stories happening in the industry and sometimes I have been a part of the story. This is MY context!

I say - "Indian context" because there is more that one story that is same except that people and projects are different within India.

I am happy that you came out with the point that made me speak of the importance of context!

Rajesh Kazhankodath said...

Pradeep,
The points you have mentioned are very much appropriate and highlights to the very core of developer tester relationship. I remember in my early days as a tester, I used to get furious when developers mark the bugs logged by me as "not reproducible" or "not a bug". Over the years I've sharpened my defect logging style to give in as much information as possible in the defect report and also pick up the phone and explain in case things do not go as expected.
Generally young developers develop a "my baby" attitude towards their code that makes then averse to any criticism of their work. To hold your ground is the best approach I’ve seen being adopted by seasoned testers. There’s been occasion in by organization where major releases where held up my testers and issues being escalated to the highest level. Often after a major show down the testers always have the upper hand since testers are often revered as the custodian of the customer interests. We need to keep this always in our mind; we have nothing to lose anyway so long as the defect data justifies our stand.
I’ve also seen developers not inviting testers to review meetings, the reason they often cite “its too technical for you!”. Often times these discussions gives vital inputs to testing. As you have rightly mentioned, the “Jargon menace” favors the developers but make it a point to jot down the jargons you don’t understand and do a google search to find out more. Often times a google search gives more information about the term than the developer actually know about.
We’ve also hired subject matter experts in the testing team and it makes a very good impact in getting the voice for testing team. Subject matter experts have experience working in the industry with similar or competitive products and their opinion is really valued by end users and marketing folks.
The few simple steps I follow to get appreciation you need as a tester.
• Look around and develop relationship of other stakeholders. It can be anyone from marketing, tech support, documentation, higher management, on-site consultants; anyone you feel can vouch for you.
• Speak the developer’s language; Get a handle on those terms developers throw around. Its fairly easy with google and wikipedia around.
• Hold your ground when it needs to be; remember we have nothing to lose.
• Be of help when the developers need your help.

Regards,
Rajesh

Pradeep Soundararajan said...

@Rajesh,

Thank you for the comment!

I am happy to receive your experience story. An important point I noticed about your story is your situational awareness. You analyzed the situation and reacted to it.

Although I want to argue on some of the points you mentioned I realize "what works for me might not work for you and vice versa".

It is your skills that helps you deal with such situation, NO CERTIFICATE, NO PROCESS, NO PROCEDURE, NO SCRIPT will helps a tester. Exploratory skills to the rescue!

Anonymous said...

Nice article, and sadly these things happen all the time.

For me it was much easier, because the first company I worked in had a developer/tester ratio of 1/1. Of course, the testers did not test only what was developed there, but also what was developed in other centers.

Also, developers were good ones and the communication was great.

After the first week I was already taken into consideration when I came up with issues.

Now, in another company, the developer/tester ratio is about 10/1, but there are no big problems, we manage to do our work good.
The developers are very good and we get along great. We are involved from the beginning, what we say is taken into consideration.

I think the most important thing for having a good developer/tester communication and cooperation is to have good people on both sides.

A poor tester will surely make many mistakes and in the end he loses his credibility.

A poor developer will get very defensive and treat bugs like a personal war from the tester.

The main thing is to do your work as good as you can, get to know the persons you work with, make sure what you say is understood as you say it and not interpreted.

For people working in smaller companies where testing is just implemented, this can be harder, but if you use your common sense, you should have a good collaboration with the developers (if they are good ones).

More and more companies, even small ones start hiring testers because after one or two production bugs which affect them, they realize that even the best programmers can do mistakes.

Victor

Pradeep Soundararajan said...

@Victor,

Good to see you stress on "credibility" of a tester. Also, there is no standard thumb rule to deal with those situations, it is just situational awareness and smart reactions puts a tester ( or developer ) in good terms with anyone.

Being good to a bad developer is bad and being bad to a good developer who wants to listen to you also is bad.

Unknown said...

I like your point about a development manger heading up testers being a bad thing because of bias toward the developers. In my company we decided to change this, and the Cheif Technology Officer is now boss over both development and testing, and now both are valued equally. No favoristism.

Pradeep Soundararajan said...

@dannomite,

Thanks for sharing your story. I am happy that someone or you came to point the problem and clear the traps early. Happy testing!

Anonymous said...

Hi Pradeep,

Just came across your blogspot 2 days back.Me and my test manager share a passion for testing and were impressed with your knowledge and talent.

Happy that we have one person taking leads on testing in India.We are not in India and work in the software dept of a Consumer Electronics company.

Testing here has a different dimension.Earlier we were not regarded on par with developers (as they were considered the domain experts) and all testing we did was considered secondary.The top management understood our good work and we were happy as we got to test a real product and all sophisticated testing tools.
One way to silence the developers and make them come back to you is by finding their blunders and understanding the tech info behind the product.Getting the information first may be a problem.But when you persist and try staying updated you are definitely going to be respected.

Pradeep,pls continue your good work in India and keep posting..

Regards,
Indu

Pradeep Soundararajan said...

@ Indu,

Thanks a lot for your appreciation. I would be happy if you get in touch with me over e-mail through which I can learn more about your contexts. It seems to me that you have an inspiring and interesting story and I am eager to listen to it.

Convey my thanks to your manager, too.