Reader Jim writes:

I wanted to ask if you have any advice on how to deal with developers when reporting/verifying bugs.

You betcha I do!

I go to great lengths to show my developers that I am their ally, not their adversary. As I've said before, my job is not to write test cases, and my developers' job is not to write bugscode. Our collective job is to create software that helps our customers do their jobs. While your developers may groan when you show up in their office door, good developers are embarrassed when you find bugs in their code. Treat them with respect and they will do the same in return. Here's how I show respect:

  • When I find a bug, I re-run what I *think* are the repro steps to ensure that they really do cause the bug to appear.
  • I attempt to narrow down the repro steps to get the sequence as short as possible while still demonstrating the bug.
  • I test around the bug to learn its boundaries. Oftentimes the specific bug I find is just one manifestation of a wider or deeper issue.
  • I talk with the developer about the bug before I log it. Perhaps they think it's not really a bug, in which case we need to talk that through. They may have suggestions about other things to try: "If twonking the fitzer has that effect, then try twiddling the blonk or toggling the macker". This benefits both of us: I get ideas for refining my bug report, and my developer gets a heads up about the incoming bug.
  • I take the time to craft the bug report, to make the bug clear, and to distinguish between facts that I observed - "The application is unresponsive" - and guesses or extrapolations that I am making - "The application seems to be stuck in an endless loop".
  • I don't rub their nose in the problem. Yes, maybe they made a bonehead mistake. I've made plenty of those myself. I know that I am always plenty embarrassed on my own without someone else making a big deal out of it; I've found most developers to be the same. (And yes, sometimes I do tease them about a super boneheaded mistake. But I make clear that it's all in good fun, and I fully expect to get teased back when I make a similarly spectacular goof.)
  • I don't tell my developers how to fix the bug. I certainly may show them *where* the problem is ("I traced the problem down to the flag variable changing datatypes from a long integer in function DoSomething to a short integer in function DoSomethingElse"). But I've learned (the hard way) that telling them *how* to fix it is dangerous - if you are right they may think you are trying to show that you are smarter than they are, and if you are wrong their estimation of you is likely to drop.
  • When I find that a "fixed" bug still repros, I talk with the developer to let them know it still repros for me. This opens a dialog between the two of us: they may ask me to repro it on their machine, and as they watch they say "Oh, I missed that step" - or they say "Hey, that step wasn't listed in the bug!", or it works on their machine but not on mine, or or or.... The important thing is the discussion.

As I said earlier, it all comes down to respect: you show that you respect your developers by writing clear and concise bug reports that state what the problem is, what the expected results should be, and the customer impact of the issue. I find that even the most obstinate developers respond well to repeated application of this treatment. Try it on yours and let me know what happens!


*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great coding skills required.