An important bug got rejected by dev today. It was my fault.

I included an incorrect solution to the problem. Rather than describing the bug and calling it quits, I went further and described (what I believed to be) the right solution. The dev rejected it because my solution was flawed. The dev was correct…a bit lazy perhaps, but correct.

The main purpose of a bug is to identify a problem, not to specify a solution. I think it’s okay for testers to offer suggested solutions but they should be careful how they word the bug.

For example, if tester logs this…

Expected Results: A
Actual Results: B because D needs to be used to determine E, F, and G. Please modify the operation to use D when determining E, F, and G.

Dev may read it and think, modifying the operation to use D will not work…I’ll have to reject this bug. ….um, what about the problem?

A better bug would have been the following:

Expected Results: A
Actual Results: B

Let the dev figure out how to get to A. If you have repro steps and other suitable details, the dev will probably know how to fix it. If they don’t, they know who to ask for assistance. It may even be the tester!

Am I right?


  1. Sandeep Maher said...

    If describing the solution (over and above the steps to reproduce the problem) means explaining the intended behaviour as against actual flawed behaviour I would say the defect management tool should include such comments from the tester and as you mentioned by wording it appropriately. As is words and appropriateness of it is a universal must-do not limited to defect management, isn't it.

    Without knowing the specifics of your bug and looking at it from here it seems a modification of the bug description (via a revision history) rather than rejection would have been the way to go...

    I think the testers are budding business analysts which most developers tend not to be (considering their job responsibilities especially for large applications where her/his focus is limited to development/ maintenance of a module or two). This means that the tester should use the near considerable (expected) application knowledge at her/his disposal and suggest (vehemently at times) how the functionality ought to be. This is a service which needs to be acknowledged by all & sundry including the developers. The tester's knowledge would fall short of expectations at times and maybe overruled by the developers, business analysts or even the customer. This to a tester must not be a deterrent but an acceptance of human failing with the incentive of the knowledge becoming more wholesome...

  2. Eric Jacobson said...


    Sounds like you’re saying there is value when testers add non-problem-related info to bug reports. I agree. However, one advantage of keeping the "initial" bug reports as concise as possible is getting your main point across.

    This can be understood by looking at a non-testing analogy. Have you ever received a response to your email where the responder appears to have ignored some of the email’s info? Maybe you send an email that asks:

    “What is your favorite color? What kind of music do you like? What is your salary?”

    The response may be “It is not appropriate to ask me my salary. It is none of your business…etc.”

    The responder is so distracted by the salary question, they don’t respond to the first questions. I find it irritating but I’ve noticed I can get more info by only asking people to focus on one idea at a time.

  3. Sandeep Maher said...

    Eric, Guess I was not clear enough and hence you misread my thoughts. The bug description must describe the bug fully and properly in all its ramifications. Period. Extraneous information (unrelated to the bug) would confuse matters - I agree.

    The bug must be explained clearly with the help of screenshots/other evidences as gathered by the tester. Details *as relevant* is required since being brief and then exchanging to&fro notes may impact resolution of the bug per se and even cause loss of historical bug data which is valuable even from an analysis perspective.

  4. Eric Jacobson said...

    Ah, yes. I'm with you. Once we get the initial bug understood and accepted, we can probably add all the discussion stuff afterwards.

  5. Rizwan said...

    Yap, it happened to me too. My reported bugs got rejected, I thought those were important! Reading your post, actually I got some thoughts in my mind.

    Example you provided first, in Actual Results, I think portion B because D needs to be used to determine E, F, and G is pretty much okay! If you are sure that this is reason for which there is variation between Expected Results and Actual Results, then you've done well by mentioning this. Because it'll let the dev to investigate quickly.
    I was wondering that why the bug got rejected! Because there my other path through which this result may occur. Do you got clear information about the investigation the dev did about this bug? I am just asking this because as a tester I think I should get detail explanation before If any of my bug got rejected so that I can be sure that yep the investigation was proper!

Copyright 2006| Blogger Templates by GeckoandFly modified and converted to Blogger Beta by Blogcrowds.
No part of the content or the blog may be reproduced without prior written permission.