18

We're actually using Mantis for our projects. Or should I say "we try to use". The problem with all bug trackers I know is that they're made by programmers, for programmers. So the design is non existent or totally absurd.

Of course, as a programmer, I can use mantis without problem, but how useful is a bug tracker when all the people involved** in a project find them so badly designed and so hard to use that they prefer making Google document with bullet list of the bugs they found or suggestion they might have.

I'm about to install a forum, it seem to me like a "in the middle" solution between a bug tracker and plain bullet list. At least a forum allow to monitor, and to centralize a discussion about a suggestion.

In case my concern is not clear, my question can be summarized to:

How do you handle you bug&suggestion report toward the non-technical user ?

** By involved, I DON'T mean the actual client or the end-user. I'm thinking about our integrator, project managers, and those who are involved with the QA.

Improve this question
9
  • 1
    asking explicitly for not for programmers software is obviously off-topic on programmers.SE
    – vartec
    Jul 11, 2011 at 14:41
  • 11
    @vartec The tool is intended for programmers, but in the real world, programmers are not alone, self-contained in a bubble. My reality imply to collaborate with non-programmer, even for tools that are intended for programmers.
    – FMaz008
    Jul 11, 2011 at 14:47
  • 2
    See here for the available options: en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems and decide for yourself which will best suit your needs. Also there is this opensource implementation of Stackoverflow: ra-ajax.org/… which is also a nice option
    – yasouser
    Jul 11, 2011 at 14:58
  • 3
    @vartec -- not sure how things are in your neck of the woods, but I've found that having programmers interfacing directly with customers solves many more problems than it creates.
    – Wyatt Barnett
    Jul 11, 2011 at 15:58
  • 3
    @Wyatt: sometimes you do expect some workload to be taken by first level support though... @vartec: not necessarily customers, but our Business Analysts/QA are far from being technical people... and we cannot really not talk to them you know :p
    – Matthieu M.
    Jul 11, 2011 at 17:18

6 Answers 6

Reset to default
12

We switched from Mantis to FogBugz (and Kiln) earlier this year, but the one thing we didn't change was that we don't let the "users" have access to the bug tracker at all. Some of the other department heads have read-only access, but honestly they are managers and they usually forget about it within a couple weeks. The users of our software all deal with a single troubleshooting guy who determines if it is a configuration issue, user error or a software bug. This person then acts as the gatekeeper for entering the real issues into FogBugz. This prevents our system from being cluttered up with issues that aren't really relevant.

So to answer your real question....it's not really an issue for us that the bug tracking software is "by programmers", "for programmers" because only "programmers" utilize it. Everyone else deals directly with a human.

(Note, our product is not shrink-ware and all of our users are direct employees or are working with an employee in the service department.)

Improve this answer
2
  • I like the idea of the gatekeeper. I just think we might be too tiny for now, but that's a really nice idea. ( right now, it's the project manager who's act as the gatekeeper for our end-users )
    – FMaz008
    Jul 11, 2011 at 15:07
  • 1
    Gatekeeper is good solution. But the Gatekeeper may want to use the same bugtracking software to keep track of everything reported to him/her. We have solved that by defined different "projects": "Idea's" where anyone can enter something; "Service desk" where all customer reports come in; ...; and the "Software Suite" which is the list development works from.
    – Marjan Venema
    Jul 11, 2011 at 18:47
6

We use redmine for this sort of thing. The key trick is the bulk of the users never see redmine -- they just send email to [email protected]. Using a few more advanced tricks -- mainly BCCing our redmine account and including the issue # -- we can keep updates going into redmine. For more advanced folks, we just let them use redmine directly given it is quite a bit more modern and user-friendly than MANTIS ever was.

Improve this answer
1
  • Hum, I didn't know that one. Searching for screenshot I think the GUI is way simpler. I'll have to take a look at that.
    – FMaz008
    Jul 11, 2011 at 14:52
2

Currently we're using MKS. For the non-programmers, I've set up some reports, and a dashboard with summaries that they're interested in. It means that I have to do the initial setup, but they are able to monitor the progress of defects and overall summary data on their own, once I show them how to access the reports and dashboards. They also needed some training to modify their tickets, but there will always be some training overhead. Fortunately, it was proportionate to the features involved.

Improve this answer
1

I second Redmine, and personally use The Bug Genie (yeah, cheesy name, but well-designed; if you're in a PHP environment and/or can't run Ruby for whatever reason) for issue tracking that is friendly to non-tech users.

Besides that, one of the keys is that end users never need to see more issues than the ones they put in, by default (optionally, you could have searching capability to avoid duplicate tickets, but that depends on your needs and setup). Seeing all of the issues will just clutter the interface and confuse the end user. Users in general should only see what they need to see, so project managers would only see issues for the projects they control, for example. As other have mentioned, for end users, the simpler you can make ticket submission, the better. Bonus points if you can have ticket submission that doesn't even require the tracker's UI (either via email, or through a simple form that only has the fields required to submit the ticket).

Improve this answer
1

We use "the Application Lifecycle Management features of Visual Studio", formerly known as Team Systems. One big advantage for us is that you can export a query result (like "all the requirements" or "all the bugs with a pri 2 or lower that won't be in the next release") into a spreadsheet or Project document. Project managers, end user reps, stakeholders etc can edit these files - changing the priority, updating the descriptions, assigning to someone else, whatever - and then when the file makes it back to a machine that's connected to TFS, you can hit Publish and the changes go back into the repository. Programmers work with work items directly from Visual Studio, but non-programmers never go near VS. Also there's a sharepoint site for each TFS project so you don't have to mail the documents around if people are all on the same network.

Maybe not an option if you're not a VS shop, but worth thinking about if you are.

Improve this answer
1
  • We're not, but thanks, I'm sure it will be useful for other reading that question.
    – FMaz008
    Jul 12, 2011 at 17:49
0

If you are talking QA/PM staff, then you need to evaluate various open and closed source tracking tools. Ones that have the ability to set builds, etc. are good, so that the QA/PM people can put tickets in against a specific build and when you fix an issue they can know which build to test it in.

Most propriety tools I have used are actually more tuned for non-programmers than programmers. StarTeam was one that worked pretty well for me, but I don't know if it's still around. You could customize fields and such if you like. Just make sure they don't go overboard with that.

If you are talking about end users, then you need to look at help desk software and then have your helpdesk personnel escalate to the bug tool as needed.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.