Is friendship ruining your testing career???

’m sorry to say that I have some bad news for you today…
Humans are social beings, and as such we have the instinctive and almost unavoidable need to be liked by our peers.
I’m not making this up!  Maslow went as far as listing belonging as one of the primary psychological needs in his famous pyramid, on top of Safety but less important than Esteem.
This means that for you it is (obviously) extremely important to make sure no one is running behind you with a loaded gun; but right after that it is more important for you to feel that your group likes you than it is to know they appreciate you as a professional tester.
If you haven’t understood how this is making you a bad tester, then let me explain a little further…

We are paid to criticize our peers

Our main task as testers is to criticize the work of our peers and to provide visibility into the status of our projects.
Criticising in itself is not a bad thing!
The definition of the word is actually “to consider the merits and demerits of (something) and judge accordingly“.  For example think about the movie critic who writes a positive review of a movie, or the food critic who recommends a restaurant to his readers.
For us as testers this criticism is translated, in the simplest ways, to:
- Test the product developed by our programmers and set our tests to pass or fail.
- Report bugs when something was not done in the way it should have been done.
- Raise flags when we understand the team is not working in a way that will allow the project to be released on time, on scope or with the proper level of quality.
& finally
- Write reports that give an overview of the status of our project:  Good or Bad, and why?
In short we are charged with the job of investigating the work being done by our peers, and reporting to management whether this work is good or bad for the project.
But I don’t want to get my friends into trouble…
When the work is good then we obviously have no problem telling this to our bosses.
But when the work is bad: when tests keep failing all the time, when bugs are raised in large numbers, when the application is not on the state it should have been by this stage of the project…  Then we need to come to our management with bad news that will most certainly get some of our “friends” into trouble.
It is normal to feel remorse for escalating bad news to management, specially when we know that our friends are not completely to blame for all the delays and issues happening in the development process.  So what can you do?

Maybe we need to be “team-players” and help our friends?

How about we stop reporting all the bugs in the Bug Tracking System?  Instead we can send “off-the-record” emails with issues found to our developers, and this way the statistics don’t look so bad for them.
But then what will happen when one of these bugs escapes from the system and is found by a customer?  At that time we will be asked how come we didn’t find this critical bug during the testing process???
Or maybe we can delay some of our tests because we know that the system is not ready and most of them will fail.
Then what will happen when the project manager comes and says that we are the one to blame for the delay of the whole release because we were not able to run our tests on time???
All of a sudden, because we became “team players” and didn’t do our jobs correctly, we became the focus for all the issues in the project!

The best path is to be transparent and professional in our work

It is understandable that you don’t want to get any of your “friends” into trouble, these are the same guys you are having lunch with every day and the same guys with whom you play poker or basketball one night a week.
The best way to help your team mates is by using the same tools that may harm them in order to improve the way they do their work.
For example:
Give them constant visibility into the statistics reflected by your bug findings.  Have a process and a mechanism in place that helps them to see the “story” told by the bugs being found and their trends.  Help them to use this information for their own benefit and to have the ways of proactively informing management of any issues before you get to them with the “bad news”.
Make sure they are constantly aware of your testing approach and schedule.  If you are going to be doing extensive tests on the new functionality give your team the time to have the feature ready on time, share with them the tests you will run so that they are not “surprised” by the bugs that you find.  Remember that you work together so you don’t need to “hide” your scenarios from them in order to find more bugs.
Share your results with the development before you send them management, this will give them time to add their own comments and so help you provide the best possible picture of the situation.

In two words: Working Together

It took me some years to realize this, but as testers we don’t work against our developers, we work for them!
Part of our job (among other things) is to help them write beter software, and to do this as quickly and effectively as possible.
We need to make sure they understand that we want to help, and at the same time to educate them in the ways in which they can help us to do this job better (but that I will leave how to educate them to a different post).
So, the next time you feel that your friendship is getting in the way of your work, remind yourself that you are there to help your friends in their work and not to cause them any harm.
Think about the PROFESSIONAL things you can do in order to assist them in their work.

http://qablog.practitest.com/2013/06/is-friendship-ruining-your-testing-career/