Yesterday, I wrote about systems for defect tracking. Since one of the main purposes of a tracking system is to enable a high quality process for getting bugs fixed, what does that process look like? As part of an in-class, small-group exercise, we defined a workflow for handling defects. Two other people on my team of four use a workflow similar to what we do at work.

The workflow we presented essentially looks like the diagram below. The bluish boxes are “open” state; and the grayish are “closed.” The lines show state transitions, starting at the top with a new bug report. (The system works well for tasks and new features, too; though features typically benefit from additional processes that don’t appear here.)

Click for larger

In this system, a notification (typically e-mail) is triggered at each state transition. This keeps stakeholders informed of changes that might impact them. It also helps with accountability — some people work at companies where developers, testers, and managers sometimes don’t “do the right thing” and arbitrarily close bugs. Another accountability feature is a short, recurring meeting where a group of 5-10 people review the new defect records. My workgroup meets every week to discuss all of the new records, looking for problem areas and issues that were incorrectly triaged or improperly closed.

The bug reporter and triage roles appear to vary widely between companies. On one end of the spectrum are top-down organizations where only managers or senior team members can log new defects and a senior manager performs all of the triage duties. In so-called “flat hierarchy” organizations anyone can enter defect reports, and all sorts of people are responsible for triaging and assigning. (For example, little-ole-nonmanager-me triages new defects for my relatively small area and assigns them to everyone in the group.) In this latter case, the weekly review meetings are even more important.

It’s also worth noting that the resolution-integration-verification path is usually iterative, even in the best case where the fix is perfect. Of course, if there is a problem with the software change or if it fails to resolve the problem, the cycle repeats. When a fix is successful, good software development processes require multiple integrations: first on the developer’s private branch and then ultimately on the product’s release branch. (Branch being a source control term here, of course.) Failure at any of these stages also causes the fix-integrate-verify cycle to repeat.

In some organizations — typically places with lots of hierarchy — the defect report may work its way back up the organization to the manager who first triaged it. Some places have a lot of heavyweight processes, I’m discovering. I’m also learning that many of the processes we use at The MathWorks are already quite advanced, especially with respect to testing.