How do you document the PROCESS of fixing bugs independent of product/technology

Question

It seems relatively easy to find bug tracking tools, but I'm looking for a way to document the process of fixing the defects that will track things such as: who is working on it, being sure that it does not interfere with other defects or with other stable elements of the application.

We want to facilitate appropriate communication to be sure that work is not duplicated and that we have a good sense of all the moving parts in place. We're consultants working on a complex application that is subject to many regulatory requirements.

Answer 1

This is something that your tracking tool should handle and should be built into the process flow within the tool. (That said, it doesn't always work this way)

If you're starting from nothing, you're almost guaranteed to find that what you start will need to change. Your process will evolve as you run into sticky areas and pain points at different stages of your workflow.

Things you want to have in your tracking tool:

• the ability to link related issues.
• the ability to flag duplicate issues (this can be done as a subset of linking).
• the ability define a workflow (that is, the allowed states an issue can be in and the data that has to be associated with it in order to move to one of the next allowed states)
• the ability to easily report who is assigned to what and at which stage they are in.
• the ability to link/attach relevant documentation (such as linking to regulatory requirements and so forth).

Things you may need to define as a process outside the tool:

• regression checking (this is - alas - the only way to ensure that fixes don't interfere with the rest of the application) and the escalation of any regression issues
• the flow of issue assignment (when does an issue get assigned to a tester, does it get passed back and forth if there are problems, and so forth)
• the interaction between the regulatory requirements and your process (this is almost certainly going to be something you have to define)
• how your team uses the tool

I would expect that whatever you do, initially you'll have a lot of confusion and possibly worse. What will happen is that as you get used to working with the tool you'll find areas where your initial process doesn't work as well as you thought it would. This is when you revise your process to smooth the workflow through these areas.

It will be awkward and seem excessive at first (speaking from experience here: I got my employer's development team from excel spreadsheets to using Microsoft Team Foundation Server for issue tracking and workflow - we've been using TFS for nearly a year and we're still refining the process and customizing TFS to suit our needs), but it does get better.

A few things I'd suggest from my experience:

• When emailing about items in the tracking system, use the item ID and title as the email header. If you can't automatically link emails to the item, this at least makes it easier to trace discussion and questions.
• Someone needs to "own" the tracking system and handle any customization/changes to it.
• Someone needs to "own" each issue to make sure that the issue is correctly handled. Whether this is a team lead, a project manager, or someone else, will depend on your system.
• For your first version of the process, you probably want to start with whatever your current process is plus the regulatory requirements. That's going to give you a reasonable starting point which you can refine as you find things that don't work that well.
• Where possible, try to keep the changes small and self-evident. Too much change is likely to overload your team and cause confusion - they'll already be dealing with a lot of new things as they familiarize themselves with the application, so the fewer other changes they have to deal with, the less likely it is that something will drop.

Good luck

Answer 2

@Kate Paulk mentioned many features. How to get there? Is it possible with free tools?

We use:

• highly customized Bugzilla (with custom fields added to support our custom workflow process)
• different workflows for different kinds of bugs,
• wiki to document process, maintain checklists etc. Foswiki engine
• we run custom SQL queries to track if all bugs in bugzilla follow the process, and show exceptions to that process (so bugs will not be forgotten and fell thru cracks). It is easy to publish SQL results in wiki using Foswiki plugins with hyperlinks to other wiki pages and to bugzilla.
• we track feedbacks separately (most feedbacks do not result in a bug, but some may be converted to more than one)
• and of course inevitable whiteboard with sticky notes to prioritize bugs and facilitate bug triage.

It took us years to fine-tune our process to this stage, and we are make more tweaks as needed.

All tools can send emails in certain steps, but we rely on central databases (with a web frontend) to handle status. Email is not good for that.

Our tools (bugzilla, Fos wiki, feedback) are Perl-based. It is increasingly hard to find Perl experts. There is very nice Python-based solution, TRAC, which integrates bug tracker, wiki for documentation, and subversion with code viewer (with markup in all parts to link to bug number, changeset, wiki page etc). Very neat, but converting our data will be a struggle, so we did not switched yet.

Wiki is very important part of the whole picture because it allows you to generate hyperlinked web pages with very little predefined structure (all smarts is in plugins). Unless you use abomination like Sharepoint which is easy to start with but almost impossible to customize.