I ran across an interesting idea recently from Mary and Tom Poppendieck's "Implementing Lean Software Development"
Tracking bugs is a waste, don't do it.
I can hear you saying, "What flavor of crack are they smoking"
Not to worry, I was thinking the same thing. But after letting it percolate for a bit, I'm starting to be a convert. This post is part of my process of evaluating the thought.
Let me start with a bumper sticker slogan and we can go from there.
"Bugs get fixed, Backlog gets tracked"
Personally, I'm coming from an agile perspective. I'm a Certified Scrum Master (CSM) and I like to use a kit bash of scrum and xp in my development. This means that every 30 days, the developers take as much work off the product backlog as they think they can "get done." Then they finish that work and demonstrate it for the customer. In order to "get done" it helps to have a self identified tester on the team.
A friend once told me, "A good tester has the heart of a developer ... (long pause) ... in a jar on their desk."
If you can get a former Microsoft tester, do it. They are demonic, evil, and truly wonderful people to have on your side.
Anyway, back to my subject at hand.
Work gets released when it has no bugs. Work is wrapped tightly in unit tests which proves that there are no bugs.
Therefore you have no need for a bug tracking system. If the customer (or a separate testing team) doesn't like the color scheme, or a button placement, or possibly even a really ugly exception that happens in odd circumstances, then they can put it on the backlog. The product owner then sets the priority and if it's at the top, the developers will get to it.
Try changing your thinking. It may sound like I'm simply changing the name of a bug to a feature (and I kinda am). It may sound like purely a semantics issue (or a horn-head manager move).
Here's the question to put to the CFO, "how much is your organization spending on overhead that comes from tracking bugs?"
I'm betting that it's a number that's not tracked.