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.

Comments (4)

  1. Eric Jacobson says:


    Great post!

    I agree with everything in your post except the 4th bullet (“I talk with the developer about the bug before I log it.”).  Years ago I practiced talking to devs prior to bug logging.  One day the development manager told me it takes an average developer 20 minutes to get caught up to where they were prior to being interrupted.  

    Soon after, I learned that my relationship with my devs actually improved when I stopped discussing nearly every defect I encountered.  I found that if I shifted my time from your 4th bullet to your first 3 bullets, the pre-bug-logging-discussion with devs lost most of its value because my submitted bugs were typically solid.

    These discussions don’t really go away, they just occur in a different spot…and only when necessary.  The same discussion can take place when the developer is debugging.  

    So what if we are really confused as to whether it’s a bug or not?  Log it!  Take the risk!  In the 3 companies I have worked as a tester, a quick conversation with the developers always reveals they prefer to reject a couple of phantom bugs rather than discuss each one with the tester.  The key is to not take it personally.  Per your post, just like we don’t think our devs are boneheads if they write a bug, they don’t think we’re boneheads if we log a bug that isn’t really a bug.  One could even argue that the artifact left behind by a rejected bug has value.

  2. Eric,

    I agree, and in fact I don’t discuss *every* bug with the developer; I could have been more clear on that point. As you say, a tester should never be afraid to log a bug.

    On the other hand, a tester who logs large numbers of not-bugs sinks their developers’ time as much as a tester who discusses every bug with their developers.

    It’s a balancing act. Going to extremes in either direction helps a person find where the happy middle is for them.

  3. William says:

    The points mentioned here are great when a bug is easily reproducable. How do you describe and log a fault when its not easily reproducable. ie Caused by a combination of factors throughout the application and/or the environment the application works in.

  4. For the most part, I take the same steps regardless of how completely I can describe what is occurring. As the repro steps become more complicated, or the reproducableness of the bug decreases, I am more likely to talk the bug over with my dev before I log it. As I say in my post, I find their different viewpoint invaluable in breaking through the surface symptoms to the real bug.

Skip to main content