When I was testing at Microsoft, a lot of the developers on our team would get to work around noon, and then work late into the night. Our builds came out around 8:00 am, though, so it worked out really well for me to show up early, and by the time I had most of a day’s worth of testing done, the devs were caught up on their email but hadn’t really settled into their coding. So I’d visit each dev in person and let them know what I’d worked on that day and what bugs I’d found in their features. That way I got the first round of questions and clarifications taken care of *before* I entered bugs into the tracking system, and so when I did enter them, they were clearer, more useful, and much less likely to come back to me as “tester error” or “by design”.
Except for that one guy. Every single time I brought him a bug, his instant reaction was, “the code can’t do that.” Not “are you sure?” or even “it works on my machine”, but a flat, “that can’t happen”. Every time. For dozens of bugs, over a period of several weeks.
The first couple of times, I said, “well, I’ll check it again and get back to you”, but I am and was a pretty careful tester, and I don’t usually report a bug until I’ve seen it repro and have good steps. So pretty soon, I started saying, “Can you come down to the lab with me and show me what I’m doing wrong, please?” which, happily, he was willing to do.
Once I had him in the lab, I went through my repro steps, showed him the behavior, and let him think about it for a minute. Almost invariably, he would say, “I know why that happened” and go fix it (because he really was a very good developer, he just had this problem). Eventually, he got to the point where he’d actually consider my bugs without me having to walk him through them, but only because I’d gone to the effort of figuring out how to overcome his mistrust.
The principles in play here are:
1) Being Right–We had two directly contradictory statements–“the code does this” vs. “the code cannot do that”. No amount of debate sitting in someone’s office can possibly settle a “he-said, I-said” argument, and the more you shout, the more the technical person is going to dig in his heels.
2) Solving Problems–Once I granted the developer the correctness high ground–“please show me what I did wrong”, I put him in the position of being right and of helping me solve “my” problem. It also got him into my lab space, where I didn’t have to rely on my say-so for the existence of the behavior.
3) Control What You Can Control–I can’t make the developer admit there’s a bug. I can, however, show him the bug, and let his own problem-solving tendency take him from “there isn’t a problem” to “I can solve that problem”.
4) Trust And Honesty–Over time (remember, this scenario played out many, many times over an extended period), by respecting his position, by seeking solutions instead of confrontations, and by making sure I had all my ducks in a row before I went to him, I eventually taught the developer that he could rely on me not to waste his time, and not to bring him spurious bugs. Eventually, the trip to the lab became unnecessary unless he actually needed to get his hands on the debugger.