Slashdot Mirror
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?
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?
We count the cases in production. That's how we track bugs. :-)
Bugzilla. It sucks. But that is what it is there for.
Or some such nonsense.
We did the sensible thing, we bought the JIRA stack and hooked it to Git.
JIRA, plus great integration into 'fr agile' methodology.
We have a homebrew bug tracking system I put together years ago (*). Basic stuff, problem, release,
progression through new, open, in-process, in-test, closed, rejected. Includes new features as
well as bugs, which is important. It's a huge help in getting releases
stabilized and most importantly not forgetting things. And it makes release notes easier -- you just
pull the closed bugs for that release and that's what's changed. In most people properly link
the code change coments and commit number with the bug tracking number and vice versa, which
is great for figuring out what the heck is happening in some crufty corner of the code.
And it goes back to the beginning of the project,
so once in a while an old bug report will shed light on some murky depths of the system.
But there are problems. The biggest one we have is getting test to close the bugs. Part of the
time it's because it's hard to test. Partly though I think because if the close it and it isn't fixed,
it's their problem rather than the sw devs problem. So there are literally hundreds of bugs released
to test but not tested. It's frustrating.
I guess the key is getting something everyone buys into, something that HELPS everyone rather
than makes more work for some groups.
(*) I redo either the database or the front end every few years. It's like the joke
about the axe:
"How long have you had that axe?"
"Well, nearly 20 years, of course I've had to replace the head twice
and the handle 3 times".
We begin fixing any bug as soon as it is discovered.
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.
46137
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!
But not the junior engineers who are copying and pasting code from Stack Exchange?
To track our bugs. No need for duplication of effort.
Luckily for you no senior engineers use slashdot anymore. They used to, but it's been years.
At least that was what the good teams I've worked on did. We achieved very low bug rates as in fewer than 12 during the first year of deployment of 600,000 lines of old VAX FORTRAN code that we had ported to Unix.
Then there were the ones that spent more effort tracking bugs than fixing them.
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! ;)
Anons need not reply. Questions end with a question mark.
excel for the long list. notepad for my personal (short term) list.
Scott
...
Since you're not an engineer and never will be, you're not affected by this!
We have "features"...
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.
A republic cannot succeed till it contains a certain body of men imbued with the principles of justice and honour.
Blame it on the other team.
Table-ized A.I.
Depending on organization your let someone confirm the bug and avoid dups, then you put it on the Kanban board. Alternatively you have on inside of the team confirming it.
But: why are you mixing Kanban with Scrum in the same team? That does not really make sense. Unless you switch from sprint to sprint to one or the other paradigm.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You write that you use Scrum with a kanban board, and a single list of bugs. How do you manage the list?
I don't think the problem here is necessarily the tools, but might be the process. Do you ever groom the backlog/bug list? How do you prioritise your bugs? You may wish to look a bit on the team culture and think carefully about how you are dealing with older tickets.
It also sounds like you are building up a debt of bugs, which isn't necessarily the end of the world, but you may want to ensure that you triage and process the bugs in some form.
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.
I'm in operations, not development, so I only do some little scripting, but I sit right by people who are apparently honest-to-goodness software developers. This year, I've at least gotten them to accept some tiny bit of structure and (in theory) the idea of testing things somewhere other than the production systems.
Most of our code was written by brainiacs who have since left. A lot of stuff is just a "black box" to almost everyone. We rarely know how or why it works. When it stops working, we rarely know why, and if we get it to work again, we rarely know how we did it. We don't know why feature X worked on Debian but not on Red Hat in the last release - nor do we know why it now works on Red Hat but not Debian.
There's talk of a total re-architecting. That might help.
If it weren't all being paid for with black money, we'd be in trouble.
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.
Please do not read this sig. Thank you.
>adds all bugs we find to our Kanban board
you must have a very small project or use the side of a skyscraper as a kanban board
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
We keep our backlog in version 1. We used to keep defects separately in Mantis, but at the end of the day we moved everything to version 1. When a customer calls with a bug it is tracked through RCA and to the specific code commit. That code commit is tracked to a developer and to a story that this code belongs to. Then the test plan of that story is investigated to see if it included the specific case that manifests the bug, and if it doesn't the QA who wrote that plan without explanation why that case won't be covered gets it. The developer gets it too ... We hold every now and them post mortems with the entire team and discuss the RCA and why it slipped through. Usually bugs of that type are not repeated. This works because our team sits in the same building, talks the same language or have real bilingual proficiency, and don't leave every 3 months.
My team uses Visual Studio Term Services. It's easy to get started, free for a small team, in the cloud, and has lots of features for Agile.
What ad revenue? I use adblock you fat retard.
You're the exception then. Everyone else doesn't use adblock.
OSTicket http://osticket.com
Yes, no one else uses the most popular plugin for web browsers...
Holy shit you're delusional !
And what "everyone else"? The five people a month that mistakenly end up at your site and close the tab the instant they see your face?
You've never had so much traffic as in the last week! You owe me, doughboy!
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.
The email noise is a big one. If someone reassigns a bug and comments at the same time with an attachment, make that one email, not 3!
SCRUM and Agile had a great idea - improve the process - but often the implementation of these makes it worse. Just like religions in general .
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.
We just open tickets describing the issue and toss it over the fence to the team in India to handle.... Why would we want to waste our time fixing bugs when we can pay somebody else to do it? ;-)
We write the description on a really small note and glue it to the back of a suitable insect or arachnid. Then it is let loose near the cubicle of the person who is believed to have created the bug. The type of creature varies with bug severity. Misspell a tool-tip - ladybug. Crash the kernel - tarantula.
There are test management plugins that will provide better views for testing.
Testflo is a good one, also adaptivist's test management isn't bad.
They will allow you to arrange bugs per user story / requirement.
There is always the option to have a separate test management suite that can integrate with Jira, like QASymphony's solution, there are a couple of other good ones as well, all provide a plugin that integrates the test management with Jira.
Also for a large project that has many bugs you need to have some formula to prioritize, a matrix to define the bug's priority based on its severity (per its user story) and the importance of the user story.
It might be good to hire a test manager for a while to build a testing process in your team.
The agile way is to keep it as a backlog item until the PO feels its time to fix it.
The real way is to listen to what front line support say and fix it when the noise becomes too much.
If its not a priority for anybody, then no one cares about the bug.
What is this thing you call a bug? Software only has features.
You get your job done. Then you look at the bug database and choose a bug to fix. The sooner you get your job done, and the more bugs you fix, the better you look to the boss.
this question really needs to be asked?
An ouija board and a pack of hunting dogs.
We write all of our software carefully and thereby avoid nearly all bugs. There may be one or two bugs post release but we usually discover them ourselves and fix them fairly promptly. Why would anybody need a "bug tracker"? Better to avoid most bugs in the first place.
Incidentally, the secret to avoiding bugs is to employ the best brains.
They're all basically the same
RT, Bugzilla, JIRA, Traq
Pick one.
let me correct that before the shitstorm of asshats start applyling logic to words. the slashdot traffic specifically does not generate any revenue directly. slashdot actually does in theory cost me money for bandwidth, but it fits in the tier plan i pay for already.
the slashdot comments however do generate material for me to discuss on my blog, and non-slashdot people who visit the site do want content to read. it takes me hours and hours for all those books and blog posts and comments, but what else more interesting am i going to do with my time given my limited resources?
also - forget what i said a few weeks ago. i did mention that my income is not from ads but people buying things from me. that was actually two random people who within a week bought a book, and i projected out that weekly income several years forward.
You bought into that Agile bullshit.
... your homepage link is broken, creimer must have pwned you ...
It creates a unique hash so that the same error is not duplicated, replicates the all the stack that was instrumented with all the parameters and class variables, and the database accessed so far ( by Entity Framework) . Check it out at ErrorUnit.com
Lifes a game play to win!
My team uses several different things in pipeline, tfs for user story tracking/time tracking, an older version of tfs for bug tracking , very old vcs system. It sucks.I had asked them if we could use newer better tools. After all tools in pipeline should help the team and not be a burden instead.But, it seems the team resists change(or they dont trust me since the experience gap large).
I find phabricator a lot better.
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.
You shared your delusional karma point total on here, care to share your analytics for your website? Sales figures?
A post-it note on my desk lists all the bugs that I know about, but the testing team and users have not found yet. If they will need dedicated testing I will make a Bug or Defect issue for them, otherwise I sometimes just slip a fix in along with something else that's going to be tested.
Use of labels in Jira helps keep some of the junk findable.
I have used HP Agile Manager in combination with HP QC in ALM (or whatever the fuck) in the past and don't recommend this approach. Having the defects in a separate system that was supposed to sync across, but didn't always, made things harder not easier.
If you end up with a lot of duplicates maybe you just need to make better use of the fields in your system to keep everything sorted. HP AGM was a pile of shit but we were able to use it's tagging feature and custom views to get stuff somewhat organised.
You shared your delusional karma point total on here, care to share your analytics for your website? Sales figures?
Nope. Confidential business data.
The complete life cycle of our bugs is:
A client calls about a bug.
I write it on a yellow sticky and put it on my monitor.
Then I fix the bug, push the code.
The I remove the sticky.
It usually takes a few days, thanks to all the testing, but we don't have a backlog of bugs.
When there aren't any customer bugs, we work on removing technical debt from our products.
We are lucky. All the hard work was done 10 yrs ago. We are pretty steady and our clients don't like change. 20 yrs from now, they will probably be using the same tools, happily.
Once, 8 yrs ago, we had 20 bugs at the same time. It was traumatic. When I read that MS-Windows has 640K of bugs, I was freaked. Of course, their OS has much more complexity than our little webapp.
Makes sense to me.
If I let the data out what do I get? You would just make fun of me, like JERRY when I was growing up in the SILICON VALLEY and they thought I was stupid but just had an EAR INFECTION. The school used me as a REVENUE SOURCE. i was actually a genius but they kept me in the SLOW KIDS class because I kept failing all of the tests except reading comprehension.
The lesson is that time never changes, and if I ever figure out exactly how, to tell them.
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.
replying to yourself again? i'm just kidding - i'm not zero kevin who can not get it for hours. it only took me 1 hour. welcome to the club and all, creamer the 4th, but you're not funny - at all.
Somewhere in SILICON valley, an ass is missing a HAT! I EAT 1,500 calories a day. I am posting stories about my life and loves. My blog is earning my UNCLE more than one million dollars (think 70+ YEARS OLD).
YOU ARE posting as an AC. IF you post on my BLOG, I will look at the IP ADRESS send you a LETTER IN THE MAIL.
Redmine is nicer if you have external users. Trac is fine for internal.
I've had a meandering career which went from academia to industry programmer and back to academia. My new academic field (phylogenetics) can have a fairly high programming content, but universities don't usually have the level of organization around programming that an industrial organization does.
Shortly after I started my new job, my boss/head of lab came to me. He'd received a survey asking organizations about their programming procedures (i.e. much like this question.) Having learned about CMM (Capability Maturity Model) at my previous job, I had the perfect answer for him. "Tell them that we are a CMM level one organization".
Translated: CMM level one means everybody does whatever the heck they feel like.
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
kill everyone who came up with this "agile" retardation and pretend this never happened?
At our organisation I'm responsible for two large (sub)systems -1 DB with more than 6E12 records and one critical online and batch document processing system- and a handful of smaller ones. We don't run any software to track bugs.
We work in a way to avoid the chores of tracking bugs by dividing our software into smaller components with clearly defined interfaces. Typically, after a release where testing wasn't what it should have been, an overseeable period of instability starts and issues are dealt with until total stability sets in. Usually one person leads the development of a component and a second person is knowledgeable.
We reengineer stuff only to improve performance or quality. As interfaces are set that's not too big of a problem. (Even though making stuff simpler and better is actually very hard.)
Not saying this is applicable to any organisation. But in short I'd say to divide your problem and to fix all bugs until all issues are fixed. Have a lead developer and a backup for each component. Have an experienced developer (one that can actually code) dividing big problems up into smartly smaller ones.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Some day I'll start collecting a set of "Anti-Patterns in Technical and Techno-affine Bureaucracies". One of those antipatterns will be called "Redemption by Tool": in which people settle on a tool long before they've understood the problem they are trying to solve.
what, no more hosts file posts?
Project management
The answer is out there. Get this book or the video series.
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
The author comes across as a slightly less sane Richard Stallman but at essence he's correct. Not 100% correct, but correct enough. You may not be able to use all of that but at least when you gaze into the yawning pit of despair you'll have the consolation of knowing it didn't have to end this way.
Seriously, the answer is good project management. Not seen often these days, and the reason it's not often seen is that a good project manager will say "No" now and then, or quite often, depending. That impairs their future employability and most companies avoid having capable project managers now. (And yeah, I know, but it's still true).
Basically when you buy a dead tree newspaper the severity by which any bug should be addressed is related to which page it appears on. If your software is mentioned on page 15 then you're good. If you hit the front page then you have a critical vulnerability and you should move to addressing the bug.
We're an agency.
I'm leaving at the end of this month. :-)
We suffer more in our imagination than in reality. - Seneca
Really? You use a Kanban Board with Scrum? This is semantically nonsense, as Kanban and and Scrum are both agile methods and both use boards, but the board design is different and the roles are different.
However, we use our ticket system to track feature requests, bugs etc. and assign them to developers (actually they assign them themselves). Our "board" is digitally which helps, as the team is distributed over the country.
From the guy who shared that the "girls" call you "heavy creamer"... suddenly you're bashful? Yeah, right.... It's not "confidential", it's embarrassing.
Hey, you. The customer complained about a bug, go contact him and solve it ASAP.
What we do is first classify variations of bugs. During development testing cycles, any defect found in testing becomes a defect subtask, and is prioritized right along with any other work subtasks under our current feature.
After code is deployed into production, any reported defects are captured as a higher level defect ticket (not subtask) against the application/component, not necessarily a specific project effort. If the defect is a true production issue that must be corrected, necessary work subtasks are attached to the defect, it is corrected, tested and deployed as an independent work effort.
If the defect is either acceptable until the next release or working as designed but not intended (not really a defect), then either the defect ticket is migrated to become a new change request in the project pipeline or the defect is closed and a change request ticket is created referencing back to the defect as part of the story's requirements.
We use JIRA. All items that are believed to require a DEV ticket must get past a team of gatekeepers (Triage Team.)
Tickets are reviewed for completeness, reproduction details, any logs that may be required and sample user(s) that can be used to reproduce the issue.
The Triage team searches for duplicates and attempts to replicate and then either promotes the ticket to DEV, sends it back to the requester for more detail or closes it as a dupe and links the original.
Any support tickets that come in with the same issue are linked to the DEV and once the DEV is closed, tickets are set to Pending Rollout.
The process sucks. Support hates it because it is often a struggle to get through the obvious bugs and DEV likes it because they get less duplication.
Yes, we've been through exactly the same scenario and are now on tool 3 or 4.
Have a look at LiquidPlanner. You can view the same dataset in different ways: simple tree structure or Kanban.
But it's really a people and process problem, less so tools. What's your bug logging process? Who analyzes/replicates/logs? We found that having one bug gatekeeper solved many of our duplication issues.
I make it standard that each user form has function key access to a wiki page for help and procedural notes.
When a program exception occurs it was easy to automatically create a new wiki bug page with an error message, screen shot, stack trace, machine name, user and software version. The user can edit the wiki page if required to add additional information.
This is not ideal as duplicates occur. However, its way better than relying on user reports.
As a developer you have a very specific view of defects - one that is different from the affected user, from a tester, from your manager, from the service delivery manager, from the accountants..... There are a lot of tools for developers to track issues - which are all very similar, and (nearly) all fail miserably when it comes to managing the wider impact of a software defect. It is refreshing to hear that the model does not work for a developer either. But the model discussed here is particularly bad (that it lives in a digital Kanban doesn't change the fact that its nothing more than a list).
Defects are multi-valued and multi-media (screenshots, log files, spreadsheets, commit links). Remediation might be as simple as fixing an identified typo, or it might involved a planned program of development and testing, leading to release, combined with a marketing exercise to inform/retain your customer base...
Your bug tracking should be able to capture or link all this information together.
Regarding duplicates - these are meat and potatoes for problem analysis (particularly when the issues are being raised outside the development team). The different perspectives mean: ....
- a more complete picture of what happened (hopefully, at least one person will tell you more than "its not working")
- better resolution of the problem (when it started, what differentiates the affected users from non-affected....)
- more test cases to evaluate resolution against
- more people who may be willing to help you try out remedies
As metioned in #54548491, a good search capability is really essential - not just to link together duplicates - but to manage the knowledge encapsulated in your defect resolution (because in most cases it wasn't captured in the design).
Your setup will work fine if the definition of a story includes all the tests that will be tested as part of validating the story, and the definition of done includes all tests passing, and preferably automated. Your stories will be higher quality the first time around.
...and we ran into the same issue as you did. Many, many duplicates. We lost out on a lot of useful reporting metrics due to this. One support person knew BUG1234 was for the problem of xyz thing crashing during abc. Another support person knew that BUG5678 was for the problem of xyz thing crashing during abc. When we ran any reports about frequency of tickets assigned/linked to these other bug tickets, the numbers would be wonky. We'd go in and manually reassign linked tickets as we found them and tried to consolidate them.
Eventually I just took command of the whole thing informally, as I was the lead tier 3 support for the software at the time. I created a page to track the highest impact bugs, the ones I felt either had the most impact on users, on the business, or just on potential development in general. Instead of a thousand separate and hard-to-parse-through bug tickets with multiple duplicates, the page listed the "official" description of the bug, and "official" ticket to use, and all the previous tickets that had been used for it, each in their own columns on a table. There were additional columns, like known workarounds, potential impact on other parts of the system, etc. I would then have a senior employee who had access to closing tickets (a member of the product team, I think the product owner, I don't recall) close the duplicates, so anyone searching for bug tickets related to their issue would only see a single open one. Sometimes duplicates were still made, but since I was sort of coordinating the whole bug tracking process, I could detect them early and have them closed out.
This was a small-ish company with a product and dev team that was maybe 20 people.
It was actually very popular and started us down a path of removing technical debt that had built up over a decade. Unfortunately, by the time I was able to be employed at the company and start improving processes, their parent company was already trying to axe the dev team. We eventually did get axed and they went with an outside software instead of the internal one we developed. But that was due to decisions years and years before I showed up, so I like to think if I had gotten there earlier and started lighting fires, we could have turned the ship around.
My suggestion is to put one person, most likely the top support person, or a dev who is in close communication with the support team, in charge of just manually "making a comprehensive list". You get the benefit of a dictator essentially making everything in one readable and standardized format for searching for the tickets, and you also have someone intimately knowledgeable about the various bugs across the system and the parts of the system that are the weakest, who can get you info you need quickly, rather than requiring people to try to hunt for the info they need (like how often bugs occur, their potential impact, how the bugs affect data across the system, etc.)
It is sad, it is fiction and it is all he has. Let the retard have his dreams. Life dealt him a shitty hand and he gave up trying a long time ago. Let him eat himself to death already.
Our development is done by Indians so we just found it easier to keep a small list of things that kindof sortof work versus the mountain of shit that breaks over and over and over every fucking day.
I wish it weren't the case but so much of government IT's mission these days is little more than keeping Indians employed. What the country or its citizens need is a distant afterthought if it's even thought about at all.
It works fine, it's easy to understand, it doesn't get in the way, and it more-or-less does what we want, so we can spend our time wrestling with the bugs themselves, rather than fighting the bug-tracking system. We've used it for about 10 years now, and we're happy with it.
I don't care if it's 90,000 hectares. That lake was not my doing.
We have been using BugTrack.net for a long time. It's a hosted service and we find it simple to use. It's low cost and works. We've had few outages in over 10 years now.
The downside, we are now trying to figure out how to better integrate with Jira, because we find ourselves duplicating entries.
In addition to using Rational Team Concert for tracking our work items, we have a review board that scores the priority of the items. We used to be a much bigger program (150 people at the height); pre-agile we had an in house bug tracking program and the board would also assign the bugs broadly to teams, ie UI, database etc. That's unnecessary now that we're down to single digit numbers of developers. They used to, at least, also do things like marking them as duplicates pointing to the bug that was it was a dup of, close things as Works As Designed or assign them to System Engineering for more analysis, etc.
Stick with whatever tool your team knows how to use well... switching tools too often isn't going to make up for the minor efficiency boosts for upgrading your ticketing system. That said, maybe you want to use a new project / product / major release to use as an opportunity to introduce (but not test -- you've already done testing using a throwaway project, hopefully) a new ticketing system.
Kanban has a triage process, where you spend a bit of time doing some housekeeping on your tickets to find and eliminate duplicates and mark low-impact as "won't fix".
Later on, when you notice some bugs getting lots of duplicates filed, you'll come to the conclusion that those are pretty high-visibility bugs, which might possibly be a useful metric the next time you prioritize.
I use a single sticky note to track all of my bugs. If it doesn't fit on the sticky note, then it's either too complex (i.e. a business process problem NOT a coding problem) or my plate is already full and I can't handle adding one more thing. Like phone calls, people will repeat an issue somewhere along the line if it is actually an issue.
I also use sticky notes in meetings. Only I take smaller sticky notes with me. That way everyone realizes that once one sticky note is full that the end of the meeting has arrived. More often than not I end up with zero (an empty note - aka nothing I have to do) or just one item. Everyone else brings pads of paper and they write every little thing down.
Went to your signature link. "You're a fat retard!"
All you need is a decent tool and a reasonable methodology, and of course someone to track and enforce it.
I've used everything from a home-grown system to JIRA to Quality Center to TFS. I've seen basically no enforceable rules (which sucks) to ultra-precise rigid workflows (which really sucks).
We once had a severity 1 issue come up which we quickly fixed. Turned out it wasn't a sev1 by definition (no workaround) but since we fixed it quickly we didn't care all that much. Then a senior manager saw we had had a sev1 for the release. After explaining to him that it wasn't really a sev1, he demanded we change it because it was a blemish on the release and he wouldn't have it. Per the rules in the tool, you couldn't change anything in a bug once it was closed.
I had to call in a favor to someone I had a good relationship on the IT tools team. He wouldn't reopen it so I could change the severity, but he agreed to change it for me after I had a few other people join in on the email chain and back up my story. It took a few DAYS to make that happen.
I have done a lot of work on metrics around bugs, trends over time, etc. It can be a REAL pain if over a couple of years you've gone through process and people changes. If you care at all about trying to pull metrics,define the key fields for your data as best you can, and enforce consistent use of them.
My beliefs do not require that you agree with them.
The submitter's problem, as a few people have pointed out, is that he has no real software development lifecycle process. It sounds like the submitter lacks the experience and so does his organization. It's got nothing to do with tools. Nothing. The only solution would be to hire an *experienced* technical manager or two to have them set up a workable SDLC and keep it running. I doubt your company will do this, so expect failure.