We’re going to dig into the next major component the of the ALM, the work item tracking component.

Work Item Tracking Component

 

Not A Bug

 

What is a work item tracking system?  Essentially, it is a glorified bug tracker.  And if the world needs anything, it is yet another bug tracker.

The pet project of countless budding developers, the industry if drenched in bug tracking systems of all varieties, from the beautiful to the ghastly, and everything in between.

Over the last few years, there seems to have been a shift away from “bug tracking” towards “work item tracking.”  If you have ever watched or participated in the arguments between developers and QA about whether something is actually a “bug,” you may appreciate how “work item tracking” is a more accurate (albeit clunky) term.

 

Reinventing The Wheel

 

So what are these systems missing?  Not a whole lot, at least when you look at the whole ecosystem.  However, I’ve been hard time finding a simple and affordable solution that did exactly what I need.

Again, at MMDB, we use BugNET, and it works great.  However, there are a lot of features I’d like to see added, like better workflow control and the ability to make my custom fields first-class citizens in the system.  Obviously, as an open-source project, I could contribute these additional features, but that would not be nearly as much fun.

Many years ago at GHR Systems, we used Mercury’s Test Director (which has since been acquired by HP), and it was wonderful.  It included many of the features that I’ve been looking for ever since, and have yet to find.  It allowed us to create some simple workflows to for tracking our work, so that a bug needed a “fixed in version” before it was submitted to QA, and needed a “tested in version” before passing QA.  These things can all be enforced manually, but without the system enforcing these simple rules, they will never be followed.

 

The Silver Bullet

 

This leads to the one real feature I want to have.  It’s the catalyst for this whole thing, the one feature that got me thinking about doing this system in the first place.  Requirements association.

Again back at GHR, after a round of arguments about whether something was a bug or an enhancement, we decided yet again that we need a better way to manage whether something was a bug because it didn’t match the requirements, or whether it a enhancement because it was never covered in the requirements.

The development manager, having just finished reading Karl Weiger’s Software Requirements book, insisted that every new bug entered into the system much also reference the requirements item that it was conflicting with.

Obviously this was insane.  I don’t think the manager actually expected it to happen, but he was trying to prove a point.  It was very important that the requirements be closely followed while testing in order to truly determine whether an item was a bug, not because of the stigma of the bug itself, but because bugs were handled differently.  Bugs were prioritized in order to get them fixed quickly, while enhancements were scheduled to be reviewed and possibly implemented at a later date.  Allowing new features to be classified as bugs would cause the scope to creep out of control.

However, there was not really a good way to do this.  We could add a new field to the bug tracker, but what would go in that field?  Many of the requirements documents used Word’s outline format, which would create unique numbers for each line item, but those numbers were not consistent; if someone added something to the top of the document, the rest of the numbers would change.  Also, as we’ve described at length already, these documents were not immutable.

This got me thinking that we needed to track requirements and work items in the same system, so that there could be an inherent link between them. 

 

How It Works

 

This is the key feature.  Once the requirements are approved to some degree, the work items can be created for each feature.  Then, bugs can be logged against those features.  If there is ever a question about the requirements, the developer or QA resource can quickly view the associated requirements from inside the work item. 

If there was any conversation about the during the requirements phase about this item, it will all be there already.  If the user has additional questions, they can ask them right there, and the question and answer will be recorded as part of the history. 

By providing an easy way for people to get answers about the requirements, we trick them into building up a knowledge base about the system.  Over time, the number of repeated questions and recurring misunderstandings will decrease dramatically.

 

Here We Go

 

So that’s the idea.  This is the two major components of the system, and it’s probably enough to get started with some code.  I plan on dog-fooding this system the whole way, so at the very least I want a work item tracking system ASAP just to get myself organized.  Then I’ll build out the requirements piece and use that to define the requirements for the rest of the system.

Besides, I’m a developer.  I want to write some code.