After the Bug Report



On the other hand, if the fix is really unfinished, go ahead and reject it; send the bug back to the programmer. Maybe an obvious new bug was introduced, or some small detail was overlooked. It would be easier for the programmer to clean things up while the code is still fresh on her mind than to wait for a new bug report to filter through the system. Deciding whether to reject a fix or file a new bug report is often a tough one, but if you have developed a good working relationship with the programmers, you'll get a good result either way.

While you're at it...
While I'm checking a bug fix, I sniff around for other bugs in the same area of the application. If the code is growing or changing frequently, I can often dig up additional problems to report without much extra work. Bugs tend to cluster together, and bug fixes tend to unmask latent bugs you couldn't see before.

Even if you are under strong schedule pressure, it's worthwhile to spend a few minutes to get a few more bugs filed. Organizations that support exploratory testing are more likely to see the value of this additional effort.

Not a bug?
Ouch. It's not fun when someone says the problem you so carefully isolated and reported isn't really a problem after all. Here are a few recent cases I've been involved with:

The software I'm testing has a key component that is provided by a third party. Several times I've filed bugs that flew right back to me, with a comment that not much can be done about it. This is the point where my hackles as a customer advocate go up. Customers won't care whether the problem is in our code or someone else's. They only care that the software doesn't work. In these cases, I'll do my best to explain the impact of the problem to the customer and maybe suggest a way we can work around the problem. I'll be sensitive to the fact that a workaround might be expensive to implement.

Another example is when the programmer decides that something I think is a problem is not a problem at all. I reported a bug that could cause the user to be unable to log into the application for several hours. The developer said that this was the expected behavior, and the development manager agreed. I was out voted, but far from giving up. Rather than continuing the discussion in the bug report's comments, I sent an email to the programmer and the manager explaining why I thought it was a mistake not to fix the problem. Not only did they agree with me, but the manager also validated my opinion by posting my message into the bug's comments. But the saga didn't end there. I thought that the fix that was implemented didn't go far enough to address the problem. Since the fix did work as designed and didn't introduce any new problems, I closed it out and opened a new bug report asking for more. Given the improvement that was made, we were all able to agree that this new request is valid but a lower priority.

The key to being a good customer advocate is to consider the human elements of the development process. Practice the fine art of holding your ground on issues that affect customers while maintaining effective communication with the programmers and managers. Hopefully I've given you a few useful tips for doing that better.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.