Keeping It Simple

Remember that I said that one of the underpinnings of FogBugz is to keep everything as simple as possible? To use the product successfully, you need to keep that rule in mind. FogBugz itself is customizable (after all, it's a set of ASP or PHP pages; there's nothing to prevent you from mucking about in the source code), but you shouldn't waste time fixing things that aren't broken. In addition to keeping the program itself simple, you also need to think about keeping your bug-tracking process simple. I'll close this chapter with a few concrete suggestions on how to do that.

On the application side, avoid the temptation to add new fields to FogBugz. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of how often the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It's very important not to give in to these ideas. If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs "formally" is too much work, people will go around the bug database. At that point, your ability to track what's going on goes out the window. When bugs are swapped by e-mail, hallway conversation, and cocktail napkin, you can't trust the estimates coming out of FogBugz, you can't search effectively for duplicate bugs, and you're generally in trouble.

On the process side, you should consider training testers to write good bug reports. Meetings between the test team and the development team can also be helpful (that is, if your organization somehow enforces distance between these two teams, which I think is a bad idea anyhow).

A good tester will always try to reduce the repro steps to the minimal steps to reproduce; this is extremely helpful for the programmer who has to find the bug. Developers can also give the testers an idea of the sort of information that they find extraneous, and the sort that they find necessary, in bugs that have already been entered.

Keep track of versions on a fine-grained basis. Every build that goes off the build machine should have a unique version number. Testers need to report the version where they found a bug, and developers need to report the version where they fixed the bug. This avoids pain all around.

Everyone should be responsible for keeping the customers happy. Everyone on the team needs to at least dip into the discussion groups to see what customers are talking about, and should feel free to open cases based on discussion group comments. You may also want to have everyone review the e-mail inquiries that have ended up in the inbox project, and sort them to the correct project. This helps ensure a timely response to customers. For larger projects and teams, though, it's a better idea to have one person (or a small team of people) whose job it is to explicitly sort the incoming inquiries.

0 0

Post a comment