Bug Reporting / Issue Tracking
If you're a developer, chances are you've had some pretty obscure bug reports sent to you.
Here are some examples:
The registration is broken entirely
(it actually ended up being slightly off CSS within 1 page of a 5 step registration process)
The News image is wrong
(there are a lot of news images)
I see a white page
(i don't, how about some more detail)
That contact block bothers me
(what else bothers you?)
Reporting like this is a big time waster as you, the developer, have to start a dialog with the reporter, pull a few teeth, and eventually get to the bottom of what the problem actually is.
Sometimes you'll be in situations where you can't do anything about it. One recent experience had me contracting through three levels of companies (end customer -> primary dev firm -> secondary dev firm -> me) and I had no efficient contact with the origination of where the bugs were being reported from.
Often is the case though that you do have direct contact with the people reporting the bugs. Unless you're dealing with professional QA people, or other developers, there's a good chance you are going to need to train the reporters on what information needs to be in there.
Information needed to efficiently get to the bottom of an issue my vary between projects, but this is what I will usually request be in a bug report for web development projects:
- Brief Description
- URL
- Logged in username, or not logged in?
- Steps to reproduce
- Expected behavior
- Actual behavior
- Screenshots (if needed)
- Additional Info i.e. logins, version
The biggest frustration is when you have a lot of information and still can not reproduce the bug. When this is the case, I will try to get the reporter on the phone, or talk to them face to face if you have these luxuries. (not IM)
People will talk more than they type and things will just come out of their mouth as they think. Nothing is absolute but I have found what I thought would be obviously important details left out the report which the reporter didn't consider to be important.
... Which brings me to bug/issue tracking software.
There is no ideal bug reporting software to me so I'm not going to tout any to be the best. There are different characteristics to each and considerations as to where this bug reporting system lives needs to be taken into account.
Good tracking software has at least 3 things in addition to the description of the bug:
- An authenticated user base (for keeping track of who reported/commented on what)
- Issue Status flags (i.e. in progress, closed, or even more refined: not reproducible, not a bug)
- Commenting
- File Attachments
Here are a few examples:
Bugzilla: This is a popular solution that has been around for a long time.
- Free
- Runs on your own server
- Perl based
- Web UI
- Highly Configurable
- Can be a somewhat complex install
Mantis: Mantis is a very lightweight solution that will get the job done.
- Free
- Runs on your own server
- PHP based
- Web UI
- Easy install and setup
Test Tracker: TT is a GUI based solution which is supported on Win/Mac/Linux.
- NOT Free
- Runs on our own servers and desktops
- GUI (not web based)
- Highly Configurable
Liquid Planner: This is more of a project management managed solution. It goes beyond bug tracking in that it allows you to organize projects and opt to include your clients in on a per project per task basis.
- NOT Free
- Runs on their servers
- Ruby Based
- Web UI
- Not the most intuitive [/url]
Basecamp Basecamp is another project management hosted solution. The UI is not as fancy as Liquid Planner but the pricing is better.
- Not Free
- Runs on their servers
- PHP Based?
- Web UI
- Pretty simple
When using a solution like Liquid Planner or Basecamp, privacy needs to be taken into account. The fact that the data is hosted on their servers, you may not want, or be able to use something like this for legal or privacy reasons.
There are so many solutions out there and it's only important that you use one of them, or something worthy of efficiently tracking issues. If you use something like Google Docs spreadsheets, you're heading down a slippery slope with each person you get involved. Shared spreadsheets are just not the right tool for the job.
Now what about you? Post your experience with bug tracking and other solutions that may have worked best for you in the comments.
Hey Mike, thanks for your
Hey Mike, thanks for your informative article.
Hey mike, nice article, just
Hey mike, nice article, just a comment on the subject from someone who often takes time to mention bugs for feedback and does some interface testing.
One big bug of users feeding-back is when there question does not fit inside the areas listed in a dropdown box or something. so many sites ive seen with integrated feedback do not allow for even an "other" option. leads users to feel there input wont be wanted, and they generally leave. Always be aware (as mentioned in the article) of users whos problems dont fit the pigeon hole, these are probably the problems that most need fixing.
Post new comment