Internal and External Bug-Tracking Setup

Question

Most of you certainly use some kind of bugtracker. Maybe internally only, once a customer files a bug via email or phone you add a new ticket by yourself. Sometimes weekly project meetings can be great source of new tickets coming preferably in flavors of excel sheets that the PM on the other side of the table loves to maintain and chase after you.

The more advanced (and transparent) version: Allow the customer to file (and see the progress of) his bugs directly into you bugtracker. Systems like JIRA allow you to use profiles to have certain access rights, etc.

But now the question: The bug raised by a user not necessary translates into 1 bug in a specific module/method/EJB/class. The version of the (your) web application he uses does not translate into the version of the class that is causing the error. How you maintain the internal part of the ticket with all the nasty techy details and the same time the make-the-user-feel-good ticket (need more info, accepted, in progress,..) ? Creating 2 tickets for internal and external ? Link them ?

Any smart recipes to share ?

Answer 1

Most sensible way is to have two systems, or an alterantive mechanism for end users to submit bugs (via email). The main problem is not so much that a bug not necessarily translates into one method in a class, but mostly that if you have more than a handfull of users, peopel wont read existing bugs and think further than "button does not work".

If you isolate the real incident system (make it public, but read only), your staff can screen incoming bugs, make sur ethey are reproducable and have repro cases, check against existin bugs and in general have a clear bug once you enter it, and not soe hard to understand mess that may or may not ven make sense and be yet another entry of the same bug entered another 30 times already.

Answer 2

Separate your bug system from your customer support tracking system, and allow links between them.

• Bugs can refer to zero, one or more customer support tickets.
• Customer support tickets may refer to zero bugs (e.g. the customer's problem has nothing to do with your software), one bug (in case it's really a problem in your software) or more than one bug (shit happens).

Make queries like:

• Which customers are waiting for a solution of bug X
• Which customers are waiting on open critical bugs
• Which bugs were already encountered by user Y
• ...

You will also notice that each database will have its own 'speed'. In my situation I have about 4 times more customer support calls than real bugs.

Answer 3

Each comment in JIRA has a "Viewable By" field that allows you to set the Group or Project Role to whom the comment is visible. You could use that to hide the "nasty techy details".

Alternatively you're probably on the right track when you say create two issues and link them. This has the added benefit of hiding your internal workflow from the customer.

Answer 4

One system for both (external) Help Desk and (internal) Issue Tracking. As long as you have complete control over visibility of tickets/issues, and can link between external/internal items, then this is no big deal.

Read more:

http://countersoft.com/downloads/whitepapers/Implementing_an_Issue_Management_Platform.pdf