Should I Enter a Bug?

This is a question I've come across many times. When should you write a bug report, and when should you just send an email?

Generally speaking, it's best to be safe and enter a bug, since the bug tracking system will keep a history of any back-and-forth conversation that anybody can view. You just don't get that with email. I've seen many justifications for sending an email instead of entering a bug report, but in most cases, it still makes sense to enter a bug report.

Some common reasons for sending an email are:

1) "I don't have time to enter a bug." I'm sorry, but this is a pretty weak reason. If you have time to send an email, you have time to enter a bug. I've gotten long, drawn-out emails with detailed bug descriptions. These emails must have taken 10 to 15 minutes to write. It would have been just as easy to enter the same information in the bug tracker.

Granted, you really may be in a hurry and don't have time to do a "proper" bug report. You may not have time to confirm it can be reproduced. You may not have time to figure out who should be in the notification list. However, entering a bug with as much detail as you have and saying, "I'll clean this up tomorrow" is better than not entering a bug at all (as long as you really clean it up tomorrow). At least it will be tracked, and all stakeholders will be able to see it if they look.

Entering a quick bug will take no more than one extra minute when compared to a quick email. If you see a bug, enter it. Period.

2) "I'm not sure if it's a duplicate." For the most part, you should use the search function of the bug tracker. If you're short on time, see #1. If you wind up entering a duplicate, who cares? As long as you made an effort to find the duplicate, it's no big deal to have your bug closed in the next bug triage.

The only time this might be legitimate is if you're almost positive you've seen the bug before and can't find it in the bug tracker. Then, a quick, "I think this is a duplicate, do you know the bug number?" might be in order. However, if nobody knows the number, or you don't get a response, enter the bug. Again, a duplicate bug every once in awhile is no big deal.

3) "I don't like the bug tracker and email is just easier." There are three options: learn to live with it, find an alternative bug tracker, or find an alternative job. I've worked with many different bug trackers. Some were great. Some were horrible. I lived with the horrible trackers until they were replaced. Don't let the tool you use prevent you from doing your job.

4) "This is a serious bug, and we're going live tomorrow." It's still no excuse. Enter a quick bug (see #1). If you want to be absolutely sure the right people are aware of it, send an email saying, "I just found a show stopper. See bug #X!"

5) "I'm not sure if it's a bug." This is common. You don't want to enter a bunch of "as designed" bugs. On the other hand, you don't want bugs falling into an email void. First, find the specs and see if it is a bug. If so, enter it. If the specs aren't clear, you might email the project manager or some other engineers with a brief description of the problem. If you don't get an answer right away, enter the bug anyway.

However, this really shouldn't be a problem for your projects. A test engineer really should know the specs as well as the developers. If you don't know how the product is supposed to work, how can you test it? Of course, if you are looking at another project and stumble across what might be a bug, this is when you'll wind up having to send an email (or just hunting down the Project Manager and asking).