Older blog entries for cm (starting at number 6)

14 Dec 2002 (updated 14 Dec 2002 at 17:05 UTC) »

Sorry for the silence, Wednesday I went home early and I've been home since. I picked up a wicked cold and haven't been able to think straight.

Thanks robocoder for taking a look at the whole of DefectTrackingPatterns, I welcome your comments. Until I get my head clear, here's a short list of my brain dump of things that a good bug tracking system ought to have.

  • Users can split items (e.g. when one item actually describes two separate issues) or combine them (e.g. when several contributors submit identical items)
  • Users can associate items in groups and dependencies.
  • Old discussions or issues archived, indexed, and searched. When and how does the system and/or its users identify submissions or discussions that are re-raising old topics or issues?
  • Issues, and changes in the state of issues, are connected to the use of other tools, such as checking source code in or out
  • Users are able to perform intelligent searches on issues, i.e. something more sophisticated than searching for keywords in the bodies of issues
  • URL-style link to defect in other documents, for example http://bugzilla.mozilla.org/show_bug.cgi?id=100000
  • Allow defects to have dependencies on other defects, use to create "tracking defects" and "release requirements" defects that refer to other defects that must be closed before the parent can be closed.
  • Allow users who are neither the submitter or assigned developer or admin to put themselves on a list of users to CC email on changes (watch list)
  • Clearly differentiate between defects and RFEs
  • Able to identify and push issues that are really support questions to the appropriate persons/tools
  • Use with any web browser on any O/S
  • Allow anyone on the email-on-change list to adjust which events they wish to get email about; then the system can by default be configured to email on all non-trivial events and users can turn the noise level down

Another installment on Defect Tracking Patterns, this one discusses how an automated bug tracking tool can help programmers and other development team members keep tabs on what their assigned tasks are.

Defect Tracking As Automated TODO List

Programmers and testers need a way to know what tasks they are responsible for and what priority those tasks have.


The defect tracking system should have sort and filter features that allow maintaining an automated TODO list. Each item in the bug tracking system is assigned to one person and has a priority associated with it. The list of bugs becomes a personal, automatically updated and prioritized, TODO list.

As a developer, filter on Assigned To to see your responsibilities. Sort by Priority to track the top problems that need to be worked on first.

The Dispatcher's role in assigning and prioritizing bug reports helps to keep things flowing during the development process.

Continuing the series of diary entries on Defect Tracking Patterns

This pattern is named Use a Tracking Tool.

Post-it notes, programmer's memories, even email, are all unreliable repositories for bug reports and feature requests. All of them are also difficult to coordinate on a team of more than 2 people working together for more than a few days.


Use an automated tracking tool. The tool doesn't have to be sophisticated -- it can be a spreadsheet in simple cases -- but it must be shared.

Bug tracking software has features to help manage work. Users can create filters and sorts to assist workflow. Filter on the field Detected By with your id to show the bugs you've filed. Filter on Assigned To to see your responsibilities. Sort by Severity to track the top problems.

IBM is going to acquire Rational Software for about US $2.1 Billion. Stories are all over your favorite web sites, like this Washington Post article. How will this affect the Java/OO/Web software development world? Discuss amongst yourselves.

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.

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.
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.
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.
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:

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.

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.

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

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!