Ask Slashdot: How Does Your Team Track And Manage Bugs In Your Software?

Slashdot reader jb373 is a senior software engineer whose team's bug-tracking methodology is making it hard to track bugs. My team uses agile software methodologies, specifically scrum with a Kanban board, and adds all bugs we find to our Kanban board. Our Kanban board is digital and similar to Trello in many regards and we have a single list for bugs... We end up with duplicates and now have a long list to try and scroll through... Has anyone run into a similar situation or do things differently that work well for their team?
The original submission ends with one idea -- "I'm thinking about pushing for a separate bug tracking system that we pull bugs from during refinement and create Kanban cards for." But is there a better way? Leave your own experiences in the comments. How does your team track and manage bugs in your software?

Comments

Bugzilla

[110010001000]

Bugzilla. It sucks. But that is what it is there for.

Re:Bugzilla

[Anonymous Coward]

But all of the other solutions suck worse.

We use JIRA, and have about 45,000 open issues (word Atlassian uses rather than bug). The search sucks, and it's nearly impossible to find what you're looking for. At least the Bugzilla bug list page has some sort of logic even if you can't tell what it is. We do four hour bug grooming meeting each week to prioritize bugs, but that typically gets ignored and customer complaints are always what is pushed to the top. Our workflow with JIRA is so overly complicated and depends on who opened the issue, the type of issue, and other options so everyone is always confused as to how to handle workflow even though we've used it for over five years. We even hired an expensive Atlassian consultant to help, but $8k later he simply made things more complicated. Bugzilla is pretty bad, but at least you know how to use it.

Re:Bugzilla

[110010001000]

Eh, that is fairly typical with software development. The truth is that no one really knows how to do it right. That is why the methodologies switch around every few years.

Re: Bugzilla

[Anonymous Coward]

Same experience here with Jira! Even after three full days of training when a group of us was hired last fall, we still usually don't know what to do. The having different workflow based upon hidden fields is just confusing as hell.

Re:Bugzilla

[vtcodger]

It.s been a long time, but I really had some experience with bug tracking starting back when the earth was young and the IBM Model 026 cardpunch ruled all. And thereafter for a number of decades.

Some thoughts:

1. The best method depends strongly on project size, personnel and culture. I've seen projects where there are so few bugs, there was literally no need to track them and others that did fine with a list of bugs on a blackboard. And I've seen software with so many bugs,peculiarities,and insanities that the buglist was overwhelming. Look at the situation and pick the simplest solution that might work.
2. In cataloging, do not try to distinguish between logic errors, flawed specs, user misunderstandings, design changes, etc. What is important initially is whether action is possibly needed, not why. Let the managers/suits prioritize, assign blame, haggle, and leave their usual trail of chaos.
3. Once you get past two dozen or so bugs, assign each bug a unique ID. Numeric (BUG00666) if you have no good reason to use some other scheme.
         [surprisingly often several bugs will turn out to be related. Describing that is mondo-klunky if you don't give the bugs nicknames]
4. Make sure the bug list(s) are easily searchable for keywords/phrases e.g. grepable on unix.
5. Don't try to track too much. Probably what you need to know is:
   1. 
       
   2. what's the problem? .
   3. what needs to be fixed? .
   4. when will it be fixed ('never' is OK sometimes)?
       
   5. when was it (purportedly) fixed?
       
   6. status (unless you maintain separate lists for new, to be fixed, thinking about it, fixed but not released, etc,etc,etc.

      NOTE: too many catagories or lists can get way out of hand.

      NOTE: Watch out for creeping beancounteritis. Trying to deal with a bug tracking system with 40 or more mandatory fields for every bug will probably result in it not being used most of the time.

6. Record the results of analyses (e.g. Those Mayan(?) characters in the display are because terminfo or the Registry is wrong (again)), somewhere. How likely doesn't matter. text in the bug list, links to emails, etc. You'll likely have to track from bug to analysis fairly often, so finding the analysis from the bug needs to be easy. The other way is usually less common so maybe you can live with keyword searching or some such.

NOTE: Erratic formatting of the lists above is courtesy of Slashdot. It manages to screw up plain old text, OL, UL. and I'm tired of arguing with it. I intended something more readable.
That's about it.

Sounds Simple.

Usually isn't Simple

JIRAA

[dmbtech]

JIRA, plus great integration into 'fr agile' methodology.

Re:JIRAA

[BigBuckHunter]

JIRA, plus great integration into 'fr agile' methodology.

We use JIRA as well, but fire all US development employees shortly after each acquisition, in order to replace them with cheaper developers in India. The developers in India do not have access to JIRA, and the few that do have access generally ignore it. Ever 4-5 years we'll delete a project queue to clean up the tickets once our customers choose not to renew their contract.

Is this not how everyone else does it?

Redmine

[labnet]

We use Redmine with an assortment of plugins.
(Recurring Tasks, Base Deface, Base Rspec, Customise Core Fields, DMSF, Edit Custom Fields, Git Remote, Wiki Extensions, Redrisk, Scrum)

Works great for us by integrating development and maintenance. + it's free and sits on its own little linux VM.

Don't write buggy code

[sgage]

My team gets around this whole issue by simply writing bug-free code from the get-go, and moving on. Saves a lot of hassle!

Re:Don't write buggy code

[hcs_$reboot]

Have you managed to ship Hello, World yet?

No, it didn't compile.

Re:Don't write buggy code

[fph il quozientatore]

Or, if you use git, just use this command:

git gud

Use a bug zapper!

[Gravis Zero]

We implemented a rule where whenever a bug is found in code, the coder has to go lick the bug zapper. It only took three hours... before we killed all the developers. It didn't fix our existing bugs but we haven't had any new bugs (or code) since! ;)

We invert the problem

[aquabat]

On our projects, we simply count the lines of code that have no bugs at all. It takes far less time, and we can keep track of the good lines on the whiteboard in the conference room.

Triage

[Dracos]

OP needs to triage the list he has, not duplicate all his bug tracking problems. One pass to get the list cleaned up now, then implement an ongoing practice of reviewing new submissions.

First, deprogram from the Agile cult

[gestalt_n_pepper]

By which I mean, this isn't a collaborative process, or more precisely, it's not improved by collaboration, as so many things *aren't.*

Then, use any database that makes sense. Preferably one hosted on your local server so it's not deathly slow and/or intermittent. Tack on any UI with a minimum of interface fluff. Add keywords. Using keywords, scan periodically for duplicates. This needs to be ONE person's job, preferably done for the first hour of each day. Never, ever fire that person.

It's a human language problem. AI isn't good enough. You still need a person familiar with your code and package to review it.

It's expensive. This is software. You have to pay to play.

Keep the numbers low

[gweihir]

If you do not, no amount of "magic" management and tracking will help. If you keep them low, however, you do not need a lot of tracking, every bug will be unique enough to be memorable or fixed fast enough to not need tracking.

Of course that means you need to have really good architects, designers and coders. Hard to get but worth the price they will ask.

Trac

[Herkum01]

I liked Trac a lot. It integrated Wiki, ticketing and Code repository information all in one and it was easier than Trac. However, it is not new or cool so developers don't think it was hip and always looking at something else.

even more agile

[senatorpjt]

I wait until some manager comes by my desk and asks me to stop whatever I'm working on and fix whatever bug someone just complained about.

Re:even more agile

[MrMr]

Sounds like you have a cheap and functional prioritization algorithm. Perhaps you should consider selling your managers?

Re:No bug tracking

[Dog-Cow]

4 hours of meetings every day? You have 4 half-time devs, and you're wondering why you can't keep up?

Depends on circumstance

[ihavnoid]

I am more of a half-hardware, half-software person, and was involved in very different projects, each with their own ways of doing it. Here are examples which did work:
- ClearQuest (ugh) with very draconian rulesets. This is for a team that has a long history of doing things, and with at least 100+ people developing something and there always are some people who won't do the right thing. Not much tight synchronization between contributors required.
- One gigantic e-mail thread where one person summarizes open issues every week, and closes them when the right code shows up on the master branch of the git repository. This involved roughly 4 people writing the code, writing test suites, writing build systems, and dealing with customer crisis. We agreed that any overhead to setup/maintain a proper bug tracking system wasn't worth the effort given the expertise of the people involved (Verilog hardware designers). Need quite a bit of tight face-to-face synchronization, but that was fine for everybody.
- Simple Bugzilla.
- JIRA with very lax policies (anybody can create, reassign, close tickets. Basically no admin/manager at all)
- Gigantic Excel table maintained by a manager/moderator.

What I learned was that
- A tool is just a tool - what actually matters is the people. Claiming a human problem to be a methodology/workflow problem isn't going to make anything work.
- Start simple - any workflow that tries to anticipate all the possible things that can go wrong will end up being overbloated, and the methodology itself will be ignored because (again) the people doesn't wholeheartedly agree with it. Start with something bare minimal and build up as you (and everybody else) understand the culture of the team.

In this case the original submitter seems to be concerned of seeing duplicates... I'd recommend one person volunteering to be the 'duplicate cleanup' agent for a while, and let that person try doing it manually for a week or two, and observe where/how dupes get created and what the cleanup job consists of. Or, just live with the duplicates and close them as they appear, if the amount of duplicates isn't that much.

Focus on human processes

[Lanthanide]

Lots of people have responded suggesting various tools or whatnot. It is quite likely that you already have a good (perhaps not the best) tool for the job, and what you actually need to do is change the processes that humans are following.

The best way to approach this is to use the "5 whys" approach, where you state the problem (or group of problems) and ask "why" 5 times to try and work out the root causes, then address them.

Eg, Problem: We have too many duplicate error reports. Why? Because testers don't know about existing bugs before raising new ones. Why? Because the testers don't search for existing issues on the backlog before raising new ones. Why? Because they haven't been trained properly.

Other possible answers for the above train may be "our backlog doesn't make searching easy" or "testers don't have a consistent way of recording issues so its difficult to find the same issue raised by different testers".

Anyway, you can do the 5 why's process yourself, but some potential root causes and responses you can take:

You have too many bugs in your software, so it's going to be hard to get on top of them no matter what processes you put in place.

* Perhaps there are developers in your team who don't have a good understanding of the system and generate bad code -> training or peer-programming might help.
* Perhaps your fundamental architecture needs to be refactored / improved / better documented to reduce the incidence of bugs.
* Perhaps your team has too much work load or is under too much pressure to get features out on time that you don't have adequate time to address your bugs, and they're building up into an unmanageable pile.
* Perhaps people on your team don't think it's their responsibility to fix bugs in their own code or they don't think it's 'fun' - someone else's job - and other people aren't proficient in that area of the code and so take longer to fix the bugs, or create new bugs in the process.
* Perhaps your team is just more interested in pushing through to 'new' things, and don't take the time to clean up bugs as they go, building new code on top of bad.

Other problems might arise from the testers.

* Perhaps you have lots of different people testing the software and raising bugs (instead of a core team of a few testers who become intimately familiar with the software), and they all have their own writing style or way of recording bugs, making it hard for any tester to know if any other tester has already raised a bug.
* Perhaps your testers just don't talk to each other - "oh yeah, I saw something like that 2 weeks ago...".
* Perhaps your testers don't search through the existing issues before raising new ones - perhaps because the tool doesn't support it well, or simply no-ones told them its a good idea to do.
* Perhaps your software doesn't have a good way of reporting bugs - if your software crashes, having consistent and common output to allow testers to identify "crash X is the same as crash Y" means they don't need to raise a second bug to report Y, instead they could just find the report for crash X (by searching for unique output in the crash) and add their new incident there.

Another thing to consider is that maybe you just need to groom the backlog from time to time. Go through and look at *all* the bugs in one sitting, and you might quickly find duplicates that you can merge/link together. You might also find that there's a bunch of bugs that you know you'll just "never" fix because they aren't important, so these could be closed or moved elsewhere to minimise the noise in the system, letting you focus just on the important stuff that matters.

Don't expect that there is going to be a 'quick fix' from adopting a new tool. It is very likely that some of the above human processes are contributing to your unmanageable backlog, and moving to a new tool won't markedly change your performance.

Re:Production Trouble Tickets

[JustAnotherOldGuy]

>One of the best features is that it was abandoned around 2010, so it is perfectly stable with no code thrash. Just keeps working the same, year after year, except when I add a plugin for a sort option or something.

I love abandoned code. It has no bugs; only errata.

Finally, someone who feels the same way I do. I like to find an application that isn't constantly being updated needlessly and is "abandoned". I build my own stuff into it, improve it as I see fit, harden it so it's secure, and never worry about some craptastic new release breaking shit and removing or mangling features I rely on.

And no, I'm not being sarcastic. Like you say, it just keeps working the same, year after year. What's not to like about that?