In my previous post “Using a Defect (Issue) Tracking Tool”, I talked about defining defect tracking process. In addition,  I mentioned that this process must be a simple process since it defines how the communication of defects would be between testing team and programming team. To keep my promise in this post, I am going to talk about the importance of having a simple process for issues tracking and the effect of such simple process on the performance of project team. In addition, I will include  a comparison between a simple and a difficult process. Of course all of this is based on my experience with both a difficult process and a simple one.

Once an issue is reported, this issue will pass by several statuses before getting it solved or otherwise not to fix. The number of statues that are there determine whether we use a simple or difficult the process.

A Difficult Process 

I had an experience with a very difficult process where there were 14 different statuses for issues logged in the issue tracker.Those statuses include:

Reported – Open – Removed – Awaiting Deployment – Tentative Removed – Removed – Partially Removed – Tentative Deferred – Deferred –  Tentative Rejected – Rejected – Tentative Ignored – Ignored !!!

The issue can transfer between several of these statuses and there were some real problems with this flow which lead to Quality Policy policy for testing team. The goal was to keep visibility and track about the statuses of issues. However, this became unachievable.  In addition, all thoses statuses were difficult for project team to understand and then to implement. Moreover, each transfer comes with a notification email which was really annoying.

A Simple Process 

One of the lessons learned from former Apple CEO, Steve Jobs, is to keep it simple. This really worked with us when I defined the process between an offshore testing team and our programming team. The process included the following statuses:

• New: issue is reported to programming team.
• In Progress: issue is being fixed.
• Checked In: issue is fixed and ready to be retested.
• Closed: issue is confirmed to be fixed.
• Re-Opened: issue is still there although it is checked in.
• Invalid: not a valid issue.
• On Hold: issue to be fixed later.

Last two statuses requires further discussion to finally decide about the issue. However, this process was efficient and helped  a lot to organize the tasks.

Hope this info helps.