Slashdot Mirror
Making the Case for Better Bugtracking Tools?
WeNeedBetterTools asks: "Help! I am trying to convince the leaders of my development organization that the quality of our bugtracking tool has a meaningful impact on the quality of products we produce. Right now, the tool we have is difficult to use because there is a high overhead to creating bugs, and they are very difficult to find in the system once they're reported. My main argument is that the easier the tool is to use, the more people will be motivated to enter bugs. My managers argue that if people aren't entering bugs, it's their own damn problem, and we ought to crack the whip until they always file every bug they possibly can. I need some solid references for my position. JoelOnSoftware has a great argument for making it simple to enter bugs, but he lacks credibility with my managers by virtue of the fact that he is also selling a bugtracking tool. Can anyone point me to any solid research on the relationship between the quality of bugtracking tool and the impact on product quality?"
Why don't your managers want to try something new? If it's price, tell them bugzilla is free, and is used by companies from Red Hat to Netscape. If it's a political issue, that's a whole 'nother story.
Also, why is there so much overhead? Entering a bug should be as simple as filling out a single HTML form. Is your UI too big and complicated? You can probably strip it down to the essentials, without discarding it entirely. Is it on more than one page? You can probably condense them into one form. Are the bugs stored in a database? You can write your own search page.
And if you said which bug software you're currently using, you could probably have gotten more specific and relevant tips on how to make the best use of it (change the configuration, prepopulate certain fields, roll your own modified templates, etc.).
Joe
http://www.joegrossberg.com
THe way I always work is simply using Bugzilla (make it the homepage on all machines for all I care!) and have the bugmaster run through all issues at least once a day, he/she can than decide who's gonna get the bugs in order to fix em and also check for dupes.
Bugzilla is by far easiest and cheapest to implement in any environment. It is free and webbased and moreover, it is very easy to customize it. If your management doesn't want to spend too much money on quality it is their problem, but keeping your work fun and somewhat easy is your own.
So just implement a solution and after a couple of weeks show the improved results to management.
Another thing to improve stuff is by implementing UnitTesting. Have developers write UnitTests before writing any code and run your unittests with every build (Contiuous Integration is Heaven for testers!!)
If Unit tests fail, it is no use testing software by hand and you can start kicking developers around.
We're all out there, somewhere, waiting to happen.
The bug tracking system is almost never the problem with an organization's quality improvement effort. Never-the-less time spent entering and retrieving information into the bug tracking system is 100% non-value added waste. It should be minimized by using good technology if it can be done cheaply. However, in no case does the software solve problems for you or prevent you from having to get your hands dirty. If your organization isn't eyeballing each and every problem, assigning ownership, prioritizing, and tracking improvements to closure, you are just going to fail more with a better system.
Bugzilla is cheap (free) and good, but even more importantly, you can see how other groups build a cradle to grave corrective action process around it. My advice to you is to give your boss a tour of the Mozilla bug tracking **process** with their copy of bugzilla as your window. Set up bugzilla on your own machine and play-test it by re-entering a few of your own bugs into it and mock-working them.
May I humbly suggest that you take a look at RT: Request Tracker instead. RT is a general purpose ticketing system, suitable not only for bug tracking, for for all kinds of organized message exchange within an organization (i.e. help desk, sales force tracking, some aspects of inventory management, etc). RT allows users to collaborate via a web interface, email, or the command line. By providing multiple interaction interfaces, RT encourages users to work with the system by communicating the way they would already, rather than working against them by forcing them to adapt to a wholly new system. If you don't like the web interface, feel free to change it. If it's still not enough, people can just use email instead -- just cc: your RT account on ticket related mails, and include the ticket number in the subject line. Hey presto, people can do almost what they were doing in the first place.
RT is written in clean, OO Perl making wise use of CPAN libraries instead of implementing everything from scratch. It will run on a variety of operating systems & databases (MySQL, PostgreSQL, Oracle). The system is well documented, easily extensible, and comes with a vibrant & supportive user community. It can even be integrated with things like pagers, so that the creation of critical tickets can send out a pager message to key personnel.
All in all, RT is a very nice, very well engineered system that IMO is far more suitable for most users than Bugzilla, for which the suitable scope is much more restricted. That's why RT is now being used in, among other places, Perl's bug tracker at rt.perl.org.
Disclaimer: My company uses RT, and I have met Jesse Vincent, RT maintainer, a handful of times, and even though I think it would be pretty cool if people switched to RT and bought support contracts from Jesse, I have nothing to gain if any of this happens. I just sincerely think that RT is better software than Bugzilla for almost all users, and would like to see development of the software continue to flourish and become accepted more widely. Spend a week messing around with RT and IMO you'll never want to go back to Bugzilla...
DO NOT LEAVE IT IS NOT REAL
In no particular order:
The system in use today is an internally developed tool. It is a web form, but it so completely fubar that most of the constructive suggestions about automated submission do not apply. We have tried. Thanks for sharing your ideas.
To expand on the fubar-ness of the tool -- as you fill out the form to create a bug, several fields will submit a request back to the server each time you change their value. There are at least 8 such fields on the entry form. Each roundtrip lasts ~3-5 seconds. When you save a bug, you're waiting ~15-20 seconds for it to save.
the quality of bugs entered is a problem, but not the primary problem. A bigger issue is that bugs don't capture information that people have about the bug, because opening, editing, and saving a bug is a major hassle. Thanks for input on this matter, but I feel it's mostly under control.
Bugzilla... I only wish we could be lucky enough to use it! When arguing to my managers for bugzilla, I have found huge resistance to the idea of using an open source tool. Which is disappointing, because we use plenty of other such tools internally (ant, JUnit, log4j, xerces, etc, etc)
putting up my own tool seems to be of limited benefit. There are too many people entering bugs (QA, developers, customer support) to generate a groundswell of support for anything other than the tool in use today.
testing is not a major problem. We have a great set of tests to cover almost every bug we've encountered.
What I'm trying to do here is convince someone that people need good tools to do good work. I expect that to be a truism, but it is not being accepted as such. Does anyone know of any kind of study showing a change in bugs filed following the introduction of an easier-to-use bugtracking system?