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.

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: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?

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.

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.