Comments on: The impact of a good or bad bug report http://thetesteye.com/blog/2009/07/the-impact-of-a-good-or-bad-bug-report/ by rikard edgren, henrik emilsson and martin jansson - with torbjörn ryber and henrik andersson Sun, 05 Feb 2012 11:36:25 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Martin Jansson http://thetesteye.com/blog/2009/07/the-impact-of-a-good-or-bad-bug-report/comment-page-1/#comment-161 Martin Jansson Thu, 30 Jul 2009 17:33:58 +0000 http://thetesteye.com/blog/?p=372#comment-161 Jonathan Kohl has written a good blog about bug reports, you can find it here: http://www.kohl.ca/blog/archives/000207.html Jonathan Kohl has written a good blog about bug reports, you can find it here:
http://www.kohl.ca/blog/archives/000207.html

]]> By: Martin Jansson http://thetesteye.com/blog/2009/07/the-impact-of-a-good-or-bad-bug-report/comment-page-1/#comment-153 Martin Jansson Mon, 27 Jul 2009 21:11:53 +0000 http://thetesteye.com/blog/?p=372#comment-153 I am sure all of us have taken the easy path once in a while and sometimes we have seen the effect of both. "The thorough bug report takes time from “normal” testing", that depends. If you spend 5 hours to give a good report and it does not give more work to other testers, it might be better than spending 30 min on a bad bug report that gives 10 or more hours of work to other testers. In larger companies the ripples of information spreading are so much larger than in smaller companies. "Do not report the bug at all!", that is a terrible path... I must have mentally blocked it.. I think this is too common and sad to say I think many managers stimulate this behavior by thinking it is good that no bugs are found. I am sure all of us have taken the easy path once in a while and sometimes we have seen the effect of both.

“The thorough bug report takes time from “normal” testing”, that depends. If you spend 5 hours to give a good report and it does not give more work to other testers, it might be better than spending 30 min on a bad bug report that gives 10 or more hours of work to other testers. In larger companies the ripples of information spreading are so much larger than in smaller companies.

“Do not report the bug at all!”, that is a terrible path… I must have mentally blocked it.. I think this is too common and sad to say I think many managers stimulate this behavior by thinking it is good that no bugs are found.

]]> By: Henrik Emilsson http://thetesteye.com/blog/2009/07/the-impact-of-a-good-or-bad-bug-report/comment-page-1/#comment-152 Henrik Emilsson Mon, 27 Jul 2009 11:13:53 +0000 http://thetesteye.com/blog/?p=372#comment-152 ... I have experienced an even easier path that some people tend to take in a similar situation: Do not report the bug at all! You do this of several reasons, but mainly it means that by reporting this you will get into trouble: this will render more job and perhaps give you attention you might not want. The last thing about attention is interesting because it might reveal other bugs that you should have seen earlier (sloppy testing) and therefore you have turned yourself into a scapegoat for many problems! So by not reporting the bug at all, this might be discovered late enough for you to have moved on to a new project and thereby not risking your job or reputation... In quite large companies where project includes outsourced team members and several departments from different countries, your effort is often measured by something else than a "job done well". E.g., a subcontractor might be measured by the number of bugs that they are responsible for; and they will try to shun the bug around to other departments or make you as reporter do insane tests in order to win some time (I have experienced such cases myself). This will lead into situations where you consider not to report the bug because it ultimately will render more (unnecessary) work in order to "support" the blameable culture that is bred within such large companies. … I have experienced an even easier path that some people tend to take in a similar situation:
Do not report the bug at all!

You do this of several reasons, but mainly it means that by reporting this you will get into trouble: this will render more job and perhaps give you attention you might not want.

The last thing about attention is interesting because it might reveal other bugs that you should have seen earlier (sloppy testing) and therefore you have turned yourself into a scapegoat for many problems!

So by not reporting the bug at all, this might be discovered late enough for you to have moved on to a new project and thereby not risking your job or reputation…

In quite large companies where project includes outsourced team members and several departments from different countries, your effort is often measured by something else than a “job done well”. E.g., a subcontractor might be measured by the number of bugs that they are responsible for; and they will try to shun the bug around to other departments or make you as reporter do insane tests in order to win some time (I have experienced such cases myself). This will lead into situations where you consider not to report the bug because it ultimately will render more (unnecessary) work in order to “support” the blameable culture that is bred within such large companies.

]]> By: Rikard Edgren http://thetesteye.com/blog/2009/07/the-impact-of-a-good-or-bad-bug-report/comment-page-1/#comment-151 Rikard Edgren Mon, 27 Jul 2009 10:46:52 +0000 http://thetesteye.com/blog/?p=372#comment-151 "but I’ve seen this happen so many times." Have you seen the easy path or the hard path often? My experience is that one bug once in a while doesn't make a big difference, but many bug reports together can bring the phenomena you describe, of course depending on the style of the developers you are working with. The thorough bug report takes time from "normal" testing, but quite often you find more bugs while digging into the first one. “but I’ve seen this happen so many times.”
Have you seen the easy path or the hard path often?

My experience is that one bug once in a while doesn’t make a big difference, but many bug reports together can bring the phenomena you describe, of course depending on the style of the developers you are working with.

The thorough bug report takes time from “normal” testing, but quite often you find more bugs while digging into the first one.

]]>