Ok, it’s been awhile since I’ve posted anything. I’ve been swamped with work and life and all that – but I still have plenty of items that I want to get posted here. So let me get back to the swing of things with a post today on managing software defects. As I discussed on a previous post, planning how you are going to manage the testing process ahead of time is critical. One of the key processes you need to have worked out prior to testing is the defect life-cycle you’re going to use.


The defect life-cycle defines what states (or statuses) your defects can reach, and how they move from one state to another. In this article I’ll be demonstrating a fairly standard approach – but it’s an approach I’ve been using for years with a lot of success. I’ll also describe some details that are specific to the software I’m currently using – TestTrack Pro by Seapine Software. Most of what I’ll describe can be leveraged over to the software you’re using, depending on it’s capabities.

First some definitions:

  • State – Status of the defect
  • Workflow – Definition of how defects move from one state to another – this is usually embedded within your testing software
  • Event – Actions that happen with a defect

Grab this picture of my sample workflow – this was created in TestTrack Pro, so you may need to tweak it to work with whatever software you are using.

The first thing you notice is a lot of boxes/rectangles with arrows going all over the place. The boxes are States and the arrows are Events. I’ll describe each one below.

Open

Initial state for defects. Valid actions for Open defects are Fix and Force Close. You would Force Close an item that didn’t require a normal fix, release, and test cycle – e.g. an entry wasn’t actually a defect or an entry resulted in an enhancement request.

Fixed

Once the Development team has fixed, unit tested, and made appropriate documentation updates, the entry should be moved to the Fixed state. Note that Fixed does not mean that the Test team is ready to look at the defect yet.

Ready To Test

Normally during testing there is a process for promoting fixed code into the Test environment and most defects (but not normally all) require this code promotion before the Test team can re-test. This is critical part of the testing process – make sure that the Development Team Lead and you have a very clear understanding on how this promotion occurs, and who moves defect entries from Fixed to Ready To Test once the code promotion occurs. The Event in the sample workflow is called Release To Test – you’ll also notice an arrow from Open leading to the Ready To Test State – not all fixes require a code promotion.

Closed (Verified)

The Development Team has fixed the defect and the Test Team has verified the fix.

Open (Verify Failed)

Sometimes fixes don’t fix the problem, and that’s what this State captures. Many people don’t use this State and instead cycle back to Open, but I prefer to track it in a separate status. I’ve argued in a previous post that the defect pass rate is an important factor in estimating test completion (as well as overall software quality). Maintaining a separate State makes calculating this ratio much easier.

Closed (Fixed)

This State is necessary, but should be used sparingly. Sometimes defects do require a fix, but don’t require a release and re-test cycle. If your software doesn’t have a good audit capability, you may want to consider not having this state – it can be abused.

Open (Re-Opened)

Just what it says. Some test managers prefer to start over again with a new defect – it’s your call.

Using the Defect Life-Cycle

So it should be obvious how you want to utilize the different States and what kind of metrics and reports you’ll need. Here’s a list to start with:

  • Developers – Their report should show Open, Open (Verify Failed), and Open (Re-Opened), perhaps with a special report for the Development Lead highlighting the Re-Opened and Verify Failed items
  • Testers – Their report shoud show Ready To Test
  • Management – Several reports would be appropriate – one highlighting overall volume and status of defects, another highlighting trends, another showing daily activity (# reported, fixed, tested), and another highlighting items of concern

Creative Commons License
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.