Testing my backbone

I’m a nice person. Well, I like to think I’m a nice person anyhow, and some people tell me that’s true too. Especially my kids, they tell me I’m the best Mum in the world. Aw shucks!

But sometimes, being nice creates problems because I want people to be nice back to me too.

This can be a real problem in software testing when faced with an aggressive and rude developer with little respect for your work.

The consequence of being ‘nice’ is that I’m as helpful and co-operative as possible with developers. Generally testers like me raise great bug reports and are very attentive if the developer requires further information.

On the down side, at some point in your working life, you are going to face an aggressive and unpleasant developer and to do your job, you are going to have to stand your ground.

And then its time for wimpy tester to find her voice and become  assertive tester.

So I’ve had to come up with some techniques to turn my wimpy ‘nice’  persona into an assertive positive voice.

For all you wimpy and not so wimpy testers out there, here they are:

1)  Rule Number 1. It’s all about the software, its not about you. Focus on your goal and don’t be distracted by outrageous and manipulative statements. Sometimes I imagine the developer yelling and screaming at the software not me.

2) Rule Number 2: Stick to the facts, and backup statements with evidence or in Cem Kaner’s language, find a credible source.

3) Rule Number 3: Don’t be bullied by an aggressive developer, raise your risks and speak your mind.

4) Rule Number 4: Keep a pleasant an even tone in all your discussions. Emotion is not required here.

5)Rule Number 5:  Focus on the commonalities. You both want the software to be delivered successfully. Work as a team even if it doesn’t feel like a team.

Remember the goal is not to get the developer to like you, its to get good software delivered. At the end of the day, you are responsible for raising bug reports and identifying risks. If some developer is determined to be aggressive, that’s their call, but if you stand your ground at least then you can complete your work with a clear conscience.

14 Comments

  1. Programmers who yell at reasonable testers are like TV watchers who yell at the weatherman. The particular difficulty for testers is that testers who are abused will turn down their sensitivity to problems of all kinds, and will refrain from reporting symptoms that are clues to bigger problems.

    Testers and programmers who are in conflict tend to forget something: neither should be telling the other how to do his or her work, and neither is ultimately responsible for decisions on what must be done for the project. If there’s disagreement on whether, or how, something should be resolved, take the points that support each side to the product owner.

    A few words for anyone who finds himself or herself involved in a conflict.

    – Is the complaint about the quality of your work? If it is, then it’s probably a good idea address the complaint, even if it’s coming in an inappropriate package.

    – If the complaint is not about the quality of your work, then consider this: whatever the emotional issue is on the part of the other person, it’s not about you, so don’t take it personally. That may be hard to do in the moment, but it’s important to remind yourself that if it’s not about you, it’s not about you.

    – You do not have to accept abuse from anyone. You are absolutely within your rights to say, “I’ll come back when you’ve calmed down,” and leave immediately. (Hint from Jerry Weinberg: if you want to get away from someone, and that person keeps following you, and you can’t get to your office, or your boss’s office, or your pursuer’s boss’s office… try the bathroom.)

    —Michael B.

    Reply

    1. Hi Michael,

      You make a valid point in defining the reason behind the complaint.

      In my personal experience, there is always a bit of validity and a bit of emotion involved. However, just because there is validity in the criticism does not justify the emotional response. I think sometimes its easy to be manipulated in this type of situation.

      I completely agree with you on the subject of abuse. I have only been in that situation once. Fortunately, I had a great boss who gave me just the advice you supplied. He must have been a Weinberg fan.

      Reply

  2. Rude and aggressive attitude from developers is usually faced by new testers (this is not the condition)
    If we find the reason of this attitude, we will see that some time developers are yelling right. The reason can be the quality of defects description or reporting a feature as a defect.
    We can mitigate the anger of developer by caring him/her.
    This can be done by
    1- Reviewing our defect reports with neutral thought and try to reproduce the problem, with description/steps provided.
    2- Discuss/communicate whenever the developers still feel trouble, understanding the root cause of reported defects

    Most of the time developers lose their temper when they are unable to reproduce defect using description/steps provided by tester.
    The more you care your mate, the more he/she will do for you, remember its proportional not the same.

    Reply

    1. Hi Jahangir,
      I totally agree with you, that we are responsible for trying to provide the most information and most developers I have worked with respond to this type of approach.

      However, you will occasionally get developers who have an agenda outside your tester/developer relationship. If a developer is being unreasonable then in order to get your job done, you are going to have to find some way of standing your ground.

      Reply

  3. Hi Anne,

    Your article is really very impressive and the rules you mentioned are valuable.

    In my personal experience, most the time test activities are at the boundaries of the projects and in that situation test team become under pressures. What should be the strategy to handle these things?

    Ehsen

    Reply

  4. Hi Anne-Marie,

    Excellent post.

    I’d also add to this that it’s not just developers who can become agressive. I’ve been in many situations where the customer, product owners or anyone else involved in the discussions can become agressive.

    Your advice is spot on.

    Rob..

    Reply

  5. I find it interesting that you mention parenting and dealing with emotionally laden developers in the same blog…

    Using the Transactional Analysis model an abusive developer is probably acting in parent mode. It’s then up to the tester if they want to get in child mode (let the abuse continue), shout/argue back (go into parent mode as well) or deal with them as an adult in a calm and factual way – what you described.

    I very rarely had issues with overly emotional developers or abusive behaviour. Manipulative, yes, but not shouting, maybe that’s a cultural thing. I found it helps if the attention is diverted to someone else, ie we’re all in the same boat, the PM doesn’t give you enough time to do your stuff, I’m pressured by the PM as well, let’s go to him/her and talk about it. That defuses the immediate situation and might actually lead to a constructive discussion – if care is taken not to paint the PM into a corner from which they can’t recover. Replacing oneself as the bad guy with someone else is no long term solution, just something to get out of a tight spot.

    Thomas

    Reply

  6. Hi Anne,

    Actually I mean, sometimes testing iterations and bug fixes take the project finish time more than our expectation and in that scenario mostly test team become under-pressure. As we know our clients/users are our first priority, we cannot annoy them due to delay in projects and we also try to strict with our quality of the product so both of things make a pressurized environment.

    Anne hopes you will understand my point. How can we overcome this situation in future projects?

    Ehsen

    Reply

  7. Great advice,

    Also doubly important to follow those rules in terms of what is recorded in the bug tracking system. VITAL there to stick to the facts, don’t get emotional etc.

    The other thing to consider is cultural dfferences, which can sometimes come into play. This can range from differences in what is considered ‘comfortable’ personal space, to machismo and bravado on the order of two ‘alpha’ animals taking each other’s measure.

    I’ve run into a few cases where (and I truely think this was cultural) the person in question would ‘bully’ all around them as long as those people allowed it to happen. It literally took standing up to the person to gain their respect and then their attitude changed 180 degrees. (it was weird)

    There have been a few (thankfully isolated) cases where I had to walk into the person’s office, close the door, and say ‘do you have a problem with me personally?’ to ‘clear the air’ as it were get them to actually see how their behavior looked from my perspective. In that case, it turned out they were not mad at me, but at the situation (which traced back to a bad spec).

    Ultimately I think rules 1 and 5 can be the most important when it comes to defusing the ‘test vs dev’ adversarial relationships that exist in some bad company cultures. The enemy is the bugs, not each other. The goal is the best possible software for the customer.

    The other rule I would add is to resolve conflicts like this face to face. It’s easy to misunderstand what someone is saying or take things wrong when it’s a comment on a bug report, and something in email. The thing you think is a slight may have just been sarcasm that didn’t come across right without tone of voice. It’s also faster to talk than type, so when in doubt, walk down to the other person’s office or desk, or call them on the phone instead of continuing a misunderstanding in a textual medium such as e-mail.

    Reply

    1. Hi Chuck, you’ve got some astute observations there and I really think they are pertinent. Many thanks. I like the additional rule too. I think its easy to get ourselves tangled in the emotional web, clearing the air (face to face if possible) is a great way of refocusing our goals.

      Thanks

      Anne-Marie

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>