How do you get clients to use your bug tracking system?

Question

on larger projects i use a simple bug tracking system that's designed to be used by clients

i have a lot of trouble convincing clients to use it (they send bug reports via email)

does anyone have any strategies they can suggested?

also, i have been playing around with a theory as to why this is the case; it goes like this:

asking a client to log a bug is like taking your car to a mechanic for a service, and the mechanic hands you the engine oil and says "here, pop that in". basically, the client has paid you to do the work, logging a bug sounds too much like work, so they want you to do it

thoughts?

Answer 1

Fogbugz... I asked my clients to open a case about their bug and i then worked on it... Its really worth a try..

Answer 2

IMHO I think it depends on what type of client it is, if you work as a freelancer for small companies then I think a excel spreadsheet filled by yourself is enough to use as a bug tracking system.

Answer 3

You probably need to point out the advantages of the bug tracking system for the customer like easier for them to see the status of the bug, prompts for mandatory information like version number etc.

Above all the argument that if they use the system their bugs will be processed faster usually does the trick.

Answer 4

A clear, concise bug report, not attached to a refund request, is about the best thing that can happen to your development effort, no matter what format it arrives in. Free QA, dude! Why would you want to hinder that process by making the customer jump through hoops to learn your bug tracking interface? Even if they're also in the software industry, maybe they come from a Bugzilla shop instead of a Fogbugz shop...

Answer 5

If they're sending their bug reports to you by email instead of using the bug tracking system, give them the email address of the bug tracking system! Of course you would have to implement the feature but it would be novel to parse the email for inclusion.

If the email is in the wrong format the bug tracker will email them back with a template that contains the correct layout for them to fill in along with the original text they sent to cut and paste accordingly.

If they still send the email to you, forward it to the bug tracking system and when you get the reply with a template, forward that info back to the client and tell them the system won't accept it. This is still a bit of a manual process but you will be training the client at the same time on the medium they prefer and they're still doing the majority of the work.

Automated Return email might look like:

From: Bug Tracker
Date: 25/3/2010
Subject: Please reformat your bug report: [original subject line]

Name: {Your Name here}
Priority: {Number here from 1 to 3}
Report below this line (when done, email to [email protected]. Thanks!

---

{ your original text }

Answer 6

Go for a House M.D. style approach:tell them straight on that you're not reading any emails concerning bug reports, they go straight to Spam folder. You've got, however, this nifty interface for logging bugs, and by using that they're making sure that you'll get to see them.

Answer 7

I second the recommendation of FogBugz. Most bug tracking software is a nuisance (I'm looking at you Bugzilla). It's just too perceived as too difficult to learn / navigate by my clients.

FB lets you have a public submission page for submitting new bugs. This is a very simple page that your clients could learn easily.

FB also lets you receive e-mails directly into the bug tracking system. As the admin, you categorize / assign incoming e-mail. Then, your client could optionally be notified when the bug is fixed.

One last plug for FB: There is a bug submission tool which lets you send a screen shot from a machine along with a bug description. This has been handy for my clients as well.

The final advise is this: Stop fixing any bugs that are not in the bug tracker. Of course you will get push-back, but not as much as you might think. If you are responsive to bugs / feature requests that are entered in to the tracking system, your clients will begin to see value. But, like little kids, they will not change if they can still get what they want by just fussing a little.

Answer 8

First, make sure your tracking system is very user friendly.

It has to be easy to access. Does your client have to go to a web page to file a bug? Is the application buried deep in the sitemap? Nobody is going to open a browser, find your site and go through numerous links just to file a bug. This can be solved by putting a link in your application (again, it has to be easy to find; like Help > Report a bug). If your client has more then one application, make sure he is directed to correct page (or pre-fill the needed fields).

Next, do not require of your client to classify the bug (like severity and whether it is in fact a bug or a feature request). Also keep number of fields low. Description and a screenshot is plenty.

Make your controls easy to use. Nothing is more frustrating like having to wrestle a datetime picker with three drop-downs when you are trying to get some work done (and of course if you select day 31 and then April, day gets reset to blank value).

If you expect a screenshot, give your client a nice silverlight control, where he can just drop the file instead of searching it all over his disk.

When your bug filler is customized so your own mother can use it, you'll still have to push a bit. Try to "forget" about the email sometime and when the call comes act surprised and ensure your client that you received no bug report from him. Of course when he insists that he did send it to your email, have an "ah" moment and inform him your email is acting "strange" lately, then ask him to resend the email. Next bug report will be filled right.

Answer 9

Set up your email server to bounce emails with the word 'bug' in it. Have the bounce report contain a link to your logging site.

(Or in reality, get a bug tracking software that allows bugs to be 'emailed' in).

Answer 10

You assert that your bug-tracking system is designed to be used by clients, yet clients won't use it. Could be something wrong with the clients, could be something wrong with the bug-tracking system.

I've always liked rt because it does have about the simplest, email-based user interface for clients.

However, I'm not suggesting that you change your bug-tracking system. What I would suggest is that you discuss the situation with some of your more friendly clients and see if you can figure out why they don't use it -- sure you've got a theory (some thoughts in your head) but do you have any data (some of the thoughts in their heads) ?

Then change to rt :-)

That last bit was a joke, what I should have written was -- then when you know what the problem really is, you can think about fixing it. Changing from system X to system Y without discussing the situation with your clients would be folly.

Even more foolish would be to start getting all snotty with your clients and bouncing back their bugs because they haven't filled out the right forms (as some have suggested). Unless that is, you are working in a secret orchard where paying clients are waiting to be plucked ripe from the tree.

Answer 11

We use bug tracking tool from BontQ. It provide account type for "Client" with default security settings. You can hide any items from clients. So I recommend to check it.