As soon as you hear about a production bug in your product, the first thing you may want to do, is volunteer to log it.
Why?
- Multiple people may attempt to log the bug, which wastes time. Declare your offer to log it.
- You’re a tester. You can write a better bug report than others.
- It shows a willingness to jump in and assist as early as possible.
- It assigns the new bug an identifier, which aides conversation (e.g., “We think Bug1029 was created by the fix for Bug1028”).
- Now the team has a place to document and gather information to.
- Now you are intimately involved in the bug report. You should be able to grok the bug.
Shouldn’t I wait until I determine firm repro steps?
- No. Bug reports can be useful without repro steps. The benefits, above, do not depend on repro steps.
- No. If you need time to determine repro steps, just declare that in the bug report’s description (e.g., “repro steps not yet known, investigation under way”) and add them later.
But what if the programmer, who noticed the bug, understands it better than me? Wouldn’t they be in a better position to log the bug?
- Maybe. But you’re going to have to understand it sooner or later. How else can you test it?
- Wouldn’t you rather have your programmer’s time be spent fixing the code instead of writing a bug report?
9 comments:
Subscribe to:
Post Comments (Atom)
RSS
It's not always good to do this though. Devs can get the impression that you are their "bug logging secretary" and every time they find a problem they may start throwing it over the wall for you to log because "testers log bugs"
Instead I would suggest letting the devs log bugs and if the bug report is bad, teach them how to log them properly. Bugs don't "belong" to testers, they are the whole teams responsibility. As a result logging bugs that are found is the responsibility of the whole team.
If you are doing it yourself rather than teaching others how to do it properly you are not fixing the core problem and you're also creating a load of extra work for yourself in the long run.
"As soon as you hear about a production bug in your product" - in my experience most of the time that happens, it's not coming from the developers but rather from customers, the customer service group, devops, etc. In that case I absolutely agree.
I've tried repeatedly to teach non-testers how to write a decent bug report, without much success. It's neither their job nor something they're likely to be as competent nor caring about. Better to sit with them, understand what's really going on (and that it isn't "user error") and doc it ourselves.
Programmers finding bugs? That can be a different story... :-)
Ardesco, you bring up some good points. I'm certainly not opposed to programmers or business analysts logging bugs. And I agree that as testers, we can coach and lead non-testers into better bug logging.
But we see some things a bit different I guess. I don't mind being a "bug logging secretary" if it benefits the team. In fact, the more responsibilities I inherit, the more valuable I become to the team.
I should probably provide more context for my post. As I wrote it, I was trying to determine the most useful way to spread development team responsibilities when an important production bug is found. I want my programmer to immediately begin investigating and working on a fix. As a tester, I want to express my commitment to helping as early as possible. In my experiences, that normal begins with a quick and dirty bug report, followed by assisting the investigation effort (e.g., reproducing the bug in a test environment), then documenting relevant details on the bug report, and finally, planning, testing, and debriefing.
My beliefs are also shaped by my observation of testers that didn't win team respect. In these cases, the testers stood on the sidelines, ignoring the production bug, until it was fixed and someone asked for QA Verification to deploy the fix. These testers don't act like part of a development team, IMO.
In the last years I saw way too many bugs awfully written by non-testers (developers, managers) and that's why I think that bugs should only be logged by testers. Why? Because testers care about their bugs. They try to provide all the details and explain it so everybody could understand. It's better to understand a bug from the beginning and then write it, than to read a non-detailed bug, investigating, asking for help and understanding it.
I am in no way suggesting that we should ignore a bug (production or otherwise) and we should definitely not sit on the sidelines. However we are not the developers "whipping boy" (or girl) who should be thrown all those "boring tasks" they can't be bothered to do themselves. We are part of a team that is making awesome software and teams should work together.
I find it deeply concerning that there is an impression that developers and managers don't care about bugs. A bug is a bad reflection on the software that they are involved in writing, don't they want to look awesome to the end client by ensuring that as few bugs as possible (no matter what they are) get through to the final product?
I remember when I was working in a big team of testers…I was the one that didn’t usually respond when someone asked: “Who wants to post this bug?” - I know, what tester am I?
I preferred to find the bugs and let other post it, although the team leader wasn’t always very happy with this approach, but we managed to get along. :)
About what you were saying in this article, I think that it’s best for the tester to post the bugs, and depending on the urgency of it, I see 2 methods:
- If there is no urgency in reporting the bug, I would find some precise steps for it, in order to limit the time (and frustration?) of the developer. It’s better to give some comprehensive steps, than to be called by the developer every time
- It things must move fast, post the bug with some basic steps and description and then further investigate it
Ardesco, thanks for the comment. I may have misunderstood you, but are you sure you don't enjoy logging bugs?
Personally, I do. Like Stephen King enjoys writing a scary novel, Eric Jacobson enjoys writing a good bug report. It takes a true craftsperson to write a good one and I love the challenge.
A few months ago I had been reading a post from Realmac Blog where they explain the template they use to log bugs. Create a template just like that, demanding some important information such as steps to reproduce or expected results would not be a way to guide those involved in logging the bug so that they at least know what information must be provided?
I think that this model is used for products that have hundreds of thousands of users, of wich you can't expect that they register bugs with all information needed to reproduce them. Can't we use the same model with people inside the company involved with the record of bugs, so that a bug can be perfectly registered by everyone instead of only a few?
P.S.: sorry for my english :)
Marcos, that seems like a good idea to me. If you need to log large amounts of bugs, using a standardized template or better yet, letting your users log bugs themselves, might be a good idea. I hadn't considered your context.
My post is about a different context; one where the whole team already knows how to log good bugs. I'm suggesting the tester may want to offer to log new bugs before other non-tester team members offer. This is a practice, others normally benefit from.