Bug Report System - Getting people to use it

Question

I've built already a bug report system. It looks like this:

It is accessed using a secret key combination detected by the JavaScript code. Not hard. It has everything - sends the standard emails to management and testers, logs the Javascript variables and current DOM HTML. We are also improving the backend of the system to act as a full bug report system. Previously, it was only via email.

The problem is, unfortunately, the bug reporters still preferred email. Even when I refused to answer their queries until they sent a bug report, they would not consistently send them.

I don't understand it, because, for them it should be easy, but they act like it was a big deal. (The appearance was slightly more complex before, but still, all they had to do, minimally, was type a subject and press SUBMIT). I can't ask them, because they really have no idea.

The second issue, more difficult, is to create a way to manage these issues that will be suitable to us developers. I actually have been satisfied managing new issues and bugs via Gmail inbox but my co-worker would like to use a system. He gets more mail than I do and has other reasons.

I am completely at a loss for what to do. My problem is solved as much as I need it to be. When I look at other bug report systems, they both look terrible and are often expensive. Moreover, if even one person reports a bug via email, it will be a disaster! We can't refuse every bug via email and then will have two bug reporting systems.

Sorry to put out all these complaints here, but maybe someone has some insightful advice that hasn't already been said.

Answer 1

It seems you are "influencing" a change in the culture, that takes time. In addition, bug management systems are a heavy cost, primarily because we have our email accounts open all day in the background, but for a bug management system, a user is asked to open yet another system which they have to learn to use, etc.

A few things you can try:

• Get project leader involved and discuss the importance of not losing bugs.
  • If there were any bugs that were missed, bring that up as a case study.
• You can have regular status meetings (or triage) that are run only by the bug reporting system.
• Send team-wide reports (esp. if your project leader can do it), that shows who opened how many bugs and how many are assigned to each engineer, that will have people realize the "benefit" they get (i.e. testers will be happy when they get fame because of the bug publicity, etc. As a tester, this was a great feature of bug management systems for me :-))
  • I have used tools that automatically generate bug reports and send them to the team or have desktop widgets, etc.
• You can consider integrating your bug management system with the emails so if an email is sent to the team along with a special address, it will automatically open a bug.
  • If someone sees an email that's a bug, they can add the bug management system alias to cc and there you go. Many incident management systems take this approach.

Despite all of this, you could still have some bugs that will be missed because people tend to start email discussions asking a behavior and very soon it turns out its a bug, and no one opens one in the bug management system. Having that email integration may help, but then such issues just have to be managed along the way...

Answer 2

If bug reporters are ordinary users, I can see why they would prefer to contact you by email. Let's imagine I'm an ordinary user and I want to report a bug.

Bug report form

First, the Report a bug form itself. Despite your attempts, it's not intuitive.

1. What should be the priority of the bug I want to report? If I put it too high, I'm afraid that the developers will blame me that I consider bugs I report to be more important than other bugs. If I put it too low, developers may never read them.

2. What's the subject? Hm. No idea. What about "A bug"? Sounds stupid.

3. The form asks to describe the bug. Should I start by saying hello to the person who will read the report, or keep it impersonal? Should I specify the context, given that the form asks to talk only about the bug itself?

4. The form asks me to attach a screenshot. But the bug is not visual. Can I skip this step? The form doesn't tell me if I can.

5. Email. Ok. What if I don't care about the response, and I'm afraid you will send me spam?

6. If I check that I want to notify everyone, would it notify every developer on a team? Every person in charge of reading bugs? Or maybe the bug report will become public and anyone will be able to read it? This looks scary.

Bug report process

Talking about the environment:

1. I want to keep a trace of the bug report, because there is some other company which received hundred bug reports from me, never answered and never solved them. When I contacted their support, they told that they never received anything from me. What a shame. With emails, I could have shown them that I actually did report something.

2. What would actually happen once I submit the form?

3. Is there a person behind that? Talking to a person is one thing. Filling a form without knowing if it's read by anyone is a different thing. You may say that having to write to bugs@example.com is quite impersonal as well; that's why in many products, you may contact a person.

"Bug" term

Finally, the terminology. What should be reported?

• If it's an unhandled exception in a software product, why would I report it? Shouldn't it be reported automatically?

  Actually, it should. This is exactly the behavior of the products such as VLC or Chrome.

• If it's an HTTP 500 in a web application, why should I report it? It should be done automatically.

• If it's an actual bug which doesn't cause an unhandled exception or an HTTP 500, then and only then the form can be used.

• If it's a feature I need, I would rather contact the company by email rather than reporting a bug, since it's not a bug.

• If it's a typo, a wrong translation, an accessibility issue, etc., again, few would qualify it as a bug. Thus, the form is irrelevant for that, and emails look more appropriate.

• If it's a legal request ("Your app erased all my files so I'll sue you."), it should be done by mail, or in some cases by email, not by filling a bug report.

• If it's something else, a feedback by email seems again more appropriate than a bug report.

Conclusion

Bug reporters may not be inclined to use the form because:

• They always did this way (see the answer by Omer Iqbal),

• They may have tried, and were trapped in those terribly complicated bug tracking systems,

• The form is not intuitive,

• The form doesn't give a hint about what will happen later,

• The form talks about bugs, which excludes a bunch of things which can be subject to feedback but which are not exactly bugs, such as typos or accessibility issues.

To encourage the users to actually use the form, you may:

• Make it more intuitive,

• Make it less impersonal,

• Explain better what will happen once the bug is submitted,

• Change the terminology, if needed.

Finally, why not mixing both emails and reporting through a form? FogBugz does that.

Or if reports by email really annoy you and you can afford being unfriendly with bug reporters, then:

just bounce the emails back to them with a brief message: "Please put this in the bug database. I can't keep track of email."