Bug Tracking and Small Software Companies
I wanted to follow up on my post about Trac. I mentioned that I’ve been looking for a good bug tracking system, but never really mentioned why. Why would I want to go to all of this trouble in the first place?
One main purpose is personal. I’ve done some PHP development in the past, and I thought having a personal bug tracking system would be nice. Web sites are a kind of software, too. Even if I’m the only one that uses it, it would be worth having a repository for various scripts and classes, along with a little bug tracking facility.
All that is nice, of course, but I actually have a larger purpose in mind. I work for a small software company. We produce point of sale software, which is basically something small retailers use for inventory control and sales. It does more than that, but you get the idea.
I’m in support, so I’m right on the front lines when it comes to dealing with bug-related issues. The problem is that we:
- Do not have a beta program for our software
- Do not use a very well-defined system for tracking bugs
- Our documentation and other such resources are spread across multiple locations
This is a huge problem, as someone supporting customers on software, because it’s difficult for me to find what I’m looking for when I need it.
The first point troubles me a lot. Do we do any testing? Sure, some. Whenever we receive a new build internally, we all fiddle with it, and will test stuff that we may have known was broken in a previous build. This is fairly unorganized. We’ve attempted to organize it in the past by assigning people to testing certain issues, but there are a couple of problems with this. First, we’re only testing issues we knew were a problem in the previous build. Invariably, things get broken that were not previously broken. Secondly, we’re all busy doing all kinds of other things, not the least of which is dealing with support issues. Sometimes it’s not that easy to work through a list of testing issues, if there is even a list in the first place.
Ultimately, this means that every release we make available to customers really is just a beta release. Every single release.
The second thing that has been a problem is our current bug tracking “system.” This pretty much involves one person acting as as a conduit between us (the support staff) and the developer. We send e-mail through and then receive responses on whether or not an issue will be fixed, and sometimes we get an indication of when (”fixed in next release”)… or not (”put on list”).
We also have version notes with each release that describe changes from build to build. Unfortunately, this is more of a list of “highlights” and not a complete list of fixes. It’s far from the true technical document we need. I see shareware programs, and even web scripts that have more in-depth release notes.
In addition, there are currently FIVE different files containing version notes, with splits occuring at major version number changes. These are fairly easy to use when you’re looking to see if a partcular issue was addressed on a specific version, but when you have a field person asking if a certain bug ever existed, and they’re not certain which version their customer is on, it can be a major pain.
One other big problem with these release notes is that in a few instances, we have specific documentation that occurs in these release notes, and only in these release notes. Sometimes I spend 30 minutes trying to find something that I should have had at my fingertips. What’s worse, I’m tying up other people who are trying to help me find the info, when they could be free to do other things (like helping out our customers). We shouldn’t have to use some DOS version of grep to find information in our release notes.
The last place we may keep bug-related information is in a customer tracking system we use called Goldmine. Goldmine has an InfoCenter facility which is kind of like a wiki, but one that was made before anyone knew what a wiki was, and it doesn’t work quite as nicely as a true wiki. The search is far from fast, and there is no linking from one page to a next, which is probably one of the greatest strengths of a wiki. In the InfoCenter, we keep notes on various hardware issues, error codes, and other such things. We also have some vendor-related information, and we try to track events like our training sessions in there as well. It’s really our largest information pool.
The issue here—problem number three—is that there is no direct cross referencing from the InfoCenter to the release notes or to the various e-mail that we send around regarding issues. We have three entirely separate forms of bug tracking and tech documentation. As you can imagine, sometimes it’s difficult to determine if certain information from one resource is related to another, plus we have to look in three places to obtain a complete picture of an issue.
This brings me back around to Trac. It’s got a great bug tracking system, which we obviously need. We’d be able to see the priority of the issues, when they were submitted, how many times they had been reported, and whether or not they had been resolved. We’d also have access to any intermediary notes, like other symptoms of the bug, temporary resolutions, etc. Not only that, but we’d have the ability to search for specific bugs easily. Trac can even syndicate changes to the wiki, version changes, issues, etc., to RSS, allowing someone to subscribe to a feed to keep up on changes without someone having to e-mail information out to alert everyone.
With Trac, we’d also have a full blown wiki. All of our documentation and release notes would be availble there. We could even link to specific tickets if we wanter to. How great would that be? No more hunting around, no more guessing… all there, right at your fingertips.
The last thing Trac offers would be a nice advantage, but probably the hardest thing to get the developer to adopt: source control. With a repository, you’d have a consistent versioning, and you’d more easily be able to have another developer get into the source without totally confusing things. (I have been bugging them to get another developer on board.) We have had several occasions in the past when we’d release a build one day, and then two days later we’d release a new build with the same version and build number. I probably don’t need to explain how wrong that is.
Anyway, I’ve been doing a little playing with Trac, and we’ll just have to see how it goes. Hopefully I can learn enough about it to sell the higher-ups on the idea so we can put it to use.
Keep your fingers crossed!