Not enough information in Bugs / Tickets [duplicate]

Question

I work in a small team of developers that supports several pieces of software that a large multi-site company uses.

We use Spiceworks to raise issues and support requests throughout the IT department not just developers.

We constantly get tickets raised with the following or similar:

"Function X is broken, please fix it, it is urgent"

Now this statement is practically useless to me, and it wastes my time and theirs whilst I try to work out the problem often only to discover it is something they had not realised or that should be assigned to someone else.

Now my question is in what ways could I try to get people to write more information in bugs? I have thought of several ideas such as a template but I am pretty sure they would be ignored.

The only thing I can think of that would almost certainly work is to refuse to action any tickets not written correctly, but I have my doubts as to whether I would be allowed to do this.

Incidentally the people raising the bugs tend to have trouble using basic computer functions so I cant ask them to do anything very technical without a great deal of effort.

Thanks all

Answer 1

Part of my job is answering help desk tickets for my team's main application, which is used by a few thousand internal users. While the semantics and the system are a little different, the basic principle is the same.

Always ask for more information if it's not immediately clear from the user's submission what behavior they are expecting and not receiving. If possible, fire up the application and look at it yourself, just in case the behavior really is so obvious that "clicking on X doesn't work" was a sufficient report. If it's internal support, a chat or telephone call may be appropriate.

Ideally, use the same phrasing used in their training or help materials to refer to the issue. Do not be afraid to ask for error messages or screen shots, or just come out and clearly ask what they were expecting to happen and did not.

Do not be afraid to ask your users to take screen shots, reboot their computer, or provide you with files. There is a certain level of computer expertise that it is simply inexcusable to not possess in today's world if you use a computer in your daily job, and if your employer or customer wishes to employ such people they should have in-office support who can assist them.

Answer 2

The problem with templates is that they tend to get too complex. People tend to overload those with fields that may provide information about the bug that sometimes help the debugging process and always burden the ticket sender.

Sure, it's might be useful to know what OS and browser the user used when they encountered the bug, but the majority of the bugs are "cross platform", yet the user is always forced to enter that data.

Even if those fields are optional, having too many of them will make the template look complex and cumbersome.

If you keep the template small it wouldn't get ignored. Essentially, you need to know two thinks about the bug:

1. What the user did
2. What went wrong.

And that's it! Put an additional "additional information" field for everything else the user deems important, and resist the tempt to put any other fields(unless it's contact information you can't get manually).

Answer 3

ticket writers need to be educated how to write tickets that are helpfull to developpers.

if i receive a

"Function X is broken"

i would reply:

what do you currently get if you execute 'X' ?

what are the steps to reproduce the broken 'X'

what exactly would you expect to happen, when "X" is executed ?

My customers have learned, that they get faster changes/fixes if they write their tickets with these items.

it is also helpful to make compliments to a customer that follows this rule

Answer 4

I'm not familiar with that piece of software but typically any bug tracking software worth its salt will require (or can be set up to require) certain fields before bugs can be submitted.

If certain users are consistently submitting poor quality reports, I'd investigate whether only certain users could submit bugs or whether some other members of staff could act as a gatekeepers.

Something you don't mention is whether any of these bugs are given a priority. Clearly if all of your bugs are coming through as high (or the same) priority, the system is being abused.

It might tempting (as others have pointed out) to simply close them as "more information required", "vague" or "unable to reproduce", but by speaking to the users to tease out more information you may learn a few things you didn't realise about how they're using the system. Even better, you might fix a showstopper early on rather than it being allowed to fester.