Bad Dev Lead! Bad! Bad!

A Diligent Reader has a doozy of a question:

As a test team lead, have you come acress scenarios where you believe that dev is incorrect in the way they interact with test?

Is there a tester anywhere who hasn't? I have yet to experience the joy of being on a team where Dev does everything exactly the way I think they should. (And if ever I do, I'm sure I'll discover I was wrong about many things!)

I am a new (and the third) test lead on this project in the last one year.

Holy cow! Your team is tough on testers!

My team has recently gotten two new manual testers. They have been on the project less that a month. As a test lead I think they are doing a jood job in finding bugs. However, occasionally they have committed mistakes while filing those bugs. The mistakes were more like an incorrect statement in the description (which didn't change or impact the bug or its repro in any way), or using the wrong feature area for filing.

Such mistakes are certainly not unexpected when people are coming up to speed, especially if they are new to testing.

Our dev lead has thrown a major screaming fit and recently did a skip level escalation around this. The management in response asked the test to look into it.


Question 1: How to deal with such devs?

I think the most important thing to do in this sort of a situation is to establish a dialog with the other party. Try starting with this: "I imagine that you see Test as a hindrance to your job, not a help. Is that true?" Then work from there. Possibly your dev lead is simply a prima donna, but more likely he is reacting to a situation in his past, an experience on your team or even as far back as his childhood. In either case, I might follow up by asking "How can I and my team help you do your job?" If he replies with "By doing your job", I would try the clueless tack: "Will you please help me understand how logging a bug to the wrong area prevents you from doing your job?" And so on. My goal would not be to get the dev lead to admit he reacted irrationally (almost certainly he didn't from his point of view) but rather to help him realize that I am listening to him and sincerely want to help him do his job. The book What Did You Say? The Art of Giving and Receiving Feedback is packed with information that can help you out here.

Question 2: This has not been the first time that the dev lead has been a pain point for the test lead. The management has chosen to change test leads than to tell the dev that these are not good tactics. How do I manage up properly?

I would approach this the same way: say to my manager, "I imagine that you don't know how much pain and frustration this dev lead causes me. Is that true?" I'm not sure whether "Yes" or "No" would be a more preferable answer! If they say "No", you can proceed to illuminate them, and attempt to determine how they could be so in the dark. If "Yes" is their answer, I would follow up with "I imagine that you place a higher value on keeping this one dev lead happy than on my entire team being able to do our jobs. Is that true?" And so on. Again, your goal is to open a dialog with your management.

Question 3: I had always been taking into account any way that the dev could be helped catering to all his requirements but the skip level escalation and management's response to that escalation just threw me off. Is there some other approach I should be trying?

Perhaps it's just the wording of your question, but it sounds like you've been kowtowing to the dev lead. This is a mistake, I think. I wouldn't want him viewing me as a ptsy who caters to his every whim, but rather as a peer who wants to ship a quality product just as much as he does and who is working within constraints just like he is. Yes I would go to great lengths to understand where he is coming from and to help him understand where I was coming from, but I wouldn't let him walk all over me either.

I wouldn't like to explore the leaving option without having first given this issue a good try.

Kudos to you for trying to improve the situation! Give it your best shot. But if the other parties won't change, don't be afraid to throw in the towel. Life is too short to spend time working with people who don't want to be a team!

Comments (1)

  1. Anutthara says:

    Couldn’t agree more with the last statement. The most common mistake that I have seen testers make is that they toe the dev’s line, no matter what. Even when the dev has no freaking clue of what he is doing. Ask the tester why this is so, and the reply is "Well, he is the dev, he must be knowing what he is doing, I am just following instructions".

    Oh, for Christ’s sake, you mean as much to the product as a tester as does your dev!!

    Please note that I am certainly not saying this is the problem of "Diligent Reader". I am just ranting on a common and random observation. 🙂

Skip to main content