Posted by Ben Simo
I have heard a variety of responses from developers in response to bugs I report. Some are good, some bad, and some are just plain ugly. Here are a few handfuls.
- That's strange.
- How'd you do that?
- It works on my machine.
- I already fixed that. You'll have it in the next build.
- No user would do that.
- That's not how you're supposed to do that.
- It's a data problem. Tell the users to fix the data.
- That's a cool bug! Show me again.
- I didn't touch that code.
- It works as designed.
- It works as coded. [Well, duh. What else would it do?]
- That's not a bug, it's a feature.
- I can't test everything.
- Thank you.
- Don't judge it, just test it.
The difference between the good and bad is often the relationship between developer and tester. Testers need developers to create something to test. Respect your developers. Communicate with respect and help turn the ugly responses into good responses.
As I've heard James Bach say: Testers don't create quality. Developers create quality.
What's your favorite bug report response?
8 Comments:
August 15, 2007-
Steve wrote:
-
-
August 18, 2007
-
Pradeep Soundararajan wrote:
-
-
August 18, 2007
-
Rajesh Kazhankodath wrote:
-
-
August 18, 2007
-
Anonymous wrote:
-
-
August 18, 2007
-
Ben Simo wrote:
-
-
August 18, 2007
-
Ben Simo wrote:
-
-
August 20, 2007
-
Anonymous wrote:
-
-
August 28, 2007
-
TestyRedhead wrote:
-
-
I had a fun one--we have the interesting situation of developing both gateware for FPGAs and the software that runs on top of it in-house. So sometimes the software guys are right when they say 'really that's a hardware problem'. Thing is, it's much easier to work around things in software, because simulating gateware after bug fixes is sloooooooow. So, I got told "that's really in hardware" to which I responded "yeah, but that doesn't mean it won't get fixed in software." I won the argument :)
My favorite bug report response is: "Reproduce this in front of me".
When developers have worked with testers who write bad reports the option that developers exercise is to call a tester to his desk asking to reproduce the issue.
Those testers who write bad reports aren't aware that the time and effort that they put in to write such a report went waste and they are losing more time when developers call them to reproduce those bugs in front of them. Also means, the testers who write bad reports do less tests or less new tests and find fewer bugs.
For those testers who join an organization where developers have seen more of bug reports, it is your responsibility to get the developer know that you aren't the one they think and your report is valuable.
I've had developer folks telling me in response to bug reports "you should not be testing that, few finishing touches remaining.".
>What's your favorite bug report response?
- One answer (using a chat session about an existing bug report):
me: This seems to me a bug, because ...
developer: If this is a bug, then this also ...
me: Hm, actually that is also a bug :-(
me: Imagine you are at your home pc, what would you say, if software from others would do that ?
He then agreed. If you know the developer personally over a longer time this helps and also both respect/appreciate each others work.
We should not forget: developers - same as we - have time constraints and would behave in a perfect world sometimes otherwise. We all are just humans and let emotions drive us.
- Another answer:
when I see that a tester closed a bug successfully :-)
about Pradeep's comment:
I refer to this as ping pong playing - when I want to highlight new testers the importance of this kind of communication. I let them start reading old bug reports with a lot of comments and to try to recreate the bugs from begin of the report.
So, they get to know that it is a waste of time by reporter AND developer when not reporting good and just creates confusion and sometimes even anger which can be avoided.
And in the end customer is the one who has to live with the results of this ping pong playing.
about Rajesh's comment:
In such cases I tell: the bug report is for me, so I do not forget to check in the next version. Works also good with mipping
@Steve:
I guess you mean the customer won :-)
I too have heard the "it's a hardware problem" excuse. It is similar to the excuse that "it's a data problem".
The question that should be asked is where is the best place to fix the problem. Some hardware problems are better fixed in software. Some software problems can be addressed with software. Some software problems can create hardware problems.
Is a memory leak a hardware problem because the hardware is running out of memory? Usually the best fix for a memory leak is to fix the software. However, if it is a small leak that does not impact the functionality of the software and more hardware can be added and the software restarted from time to time: the right place to fix it might be in hardware and process.
Is inability to print to a specific model of printer only a hardware problem? The hardware may be the source of the problem, but it might be possible to work around a hardware problem (over which we may have no control) through software.
Software is part of a greater system. It is common for people to pass the problem on to some other component of that system. Testers often have a better overall view of a system than many of the other participants in a project and can add value by suggesting additional parts of the system that can be modified to address problems.
Its a system problem. :)
Rajesh,
I too have been told that I'm testing something I'm not supposed to be testing. This seems to most often come up with issues related to usability, "negative" testing, and interaction between components.
It is important for us testers to pass on a story about why the bug is important and why it was good to test whatever they think should not be tested.
I recently overheard a tester's side of a phone conversation with a developer about a bug that was due to a very specific set of data conditions. At first, this set of data conditions might seem to be very unlikely. However, I heard the tester articulately describe a very plausible circumstance in which many users might encounter the problem.
Communicate using stories instead of just pointing to requirements. Build trust and respect with developers.
My favorite was after reporting that unplugging a cable while the program was running would cause a crash. The response I got was "Yea, and if you pour water on the motherboard the whole computer crashes." This response was given to me during a bug reporting meeting with engineering and PM.
"That is not permitted." Dev
"Well, it crashes. That is not an error or an acceptable result." TestyRedhead
"It is not permitted. The user can't do that." Dev
"Did you try it?" TestyRedhead
"No. It isn't allowed." Dev
TestyRedhead
Post a Comment