Older blog entries for cm (starting at number 2)

The common context for all these defect tracking patterns is that the bug database and the defect tracking system are internal, and used by the development team members, which may include someone in a customer-facing role who takes reports via the telephone or email and enters them into the system. A general-purpose customer support problem reporting system is outside the scope of these patterns. Some aspects of defect tracking within the development process are either too low-level or irrelevant to the general user population.

The patterns frequently reference four roles that development team members may play. These named roles have specific definitions within the patterns.

Customer
The Customer role may be played by a real end user customer, but more likely it will be a QA Tester, or another team member. The individual entering the bug report is the system is playing the Customer Role.
Programmer
The Programmer is the role taken by the person who is assigned to write code or otherwise modify system to fix the defect. A Programmer would at a minimum unit test the fix, and run any unit test suites, and may, depending on the team, run regression and integration tests.
Tester
The role of Tester is to verify the fix and validate it against the bug report. The same person may take both the Programmer and Tester roles, but the goals are different. For the Tester, the implemented fix is not considered done until it provides a satisfactory resolution to the bug report.
Dispatcher
The Dispatcher has the role of setting priorities and assigning bugs to be worked on, then following up on work. The Dispatcher also coordinates the life cycle events of a bug report between various other roles.

Keeping these roles in mind while reading the patterns is an important aid in understanding them.

Thanks to input from Linda Rising and Brad Appleton, I've worked up a set of patterns for defect tracking, which I think tie in somewhat with robocoder's work in SQA, so I'm putting a summary here.

First, some roles defined:

Customer
The Customer role is the person who files the bug report. It may be a real end user customer, or it may be a QA Tester, or an IT project team member-- In all cases, the duties are the same.

Programmer
The Programmer is the role taken by the person who is assigned to fix and regression test to make sure the fix didn't break other features in the system.

Tester
The role of Tester is to verify the fix and validate it against the bug reported.

Dispatcher
The Dispatcher has the role of setting priorities and assigning bugs to be worked on, then following up on work. The Dispatcher can coordinate the life cycle events between various other roles. The Dispatcher can be a Systems Analyst, Developer, etc.

Now the patterns:

Later I will post more diary entries about each of the patterns individually.

The more I look at it and learn about it, the more I believe my ideal software engineering environment would look a lot like the Mozilla Project. They have a community with multiple modes of communication (web, newsgroups, email, chat). Bugzilla is an excellent defect tracking system that doubles as another form of communication among developers and between developers and QA engineers. A well-done accessible and web-viewable CVS source code repository (either lxr or bonsai are good interfaces) complements the usual source code tools. Perhaps most importantly, the tinderbox, which continously builds Mozilla on Mac, including both OSX and 9.x Windows, and Linux. For all three platforms there is a clean build and an incremental build, plus there's the ports tinderbox which adds another dozen not-quite-supported builds on a variety of common and uncommon platforms.

But best of all is how Bugzilla, Tinderbox, Bonsai and the communications media all work together. On the Tinderbox, every checkin is logged against the build where the change appeared, and the who and what of the change is a link away to Bonsai. In the change entries, bug numbers link back to the entry in Bugzilla, comments in Bugzilla entries can include attachments of patches, screenshots, stackdumps, or any other supporting documents. The irc chat system has a bot which knows about Bugzilla bug numbers and the tinderbox status even!

TheMozillaProject MozillaTinderbox

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!