In my previous post “The Need for Tracking Issues (Defects)”, I talked about our story of brining the tool to the organization. However and as I said, bringing the tool is not the end of the story. In this post, the focus will be on using the issue tracking tool and defining testing process.

Tool Selection and Process Definition

Due to budget constrains, we were looking for an open source tool. We were lucky to find a tool that is web-based and easy to customize. Now it comes the time to define how the process of interaction between testing team and development team should be once an issue is reported. Unfortunately, this interaction was not defined by testing team and therefore it was very complex. After that, we ended up with 16 different issues statuses in the tool (other practical teams have only 5 statuses!!). Those statuses included cases for rejecting and ignoring issues. As we can see, this all violates one of the lessons learned from Steve Jobs which is “Keep it Simple”.

Resistance

Despite all of the above, we published our issue tracking tool after customization. That was the time we started to face resistance and trials to delay tool implementation. We (as a testing team) requested for management intervention and by doing this, the tool became a fact and using it is a must. The next was to do a training session for the tool and this was done successfully. In addition, the user manual was distributed.

Difficulties

The complex process made it difficult to use the tool. Also, I am sorry to say that some people kept falling into the same mistakes when using the tool and never learned. In addition, some of the development leads insisted to use the tool as a way of communication between testing and development which is really annoying and slowed down issues fixing. Moreover and in many cases, statuses of rejecting and ignoring the issues were the preferred (escape) option for the development leads. Then, the burden was on testing team back to (convince) the development team that it is really an issue.

In my next post, I will talk about this (amazing) process that we had and compare it with another simple process defined between testing team and the development team from an offshore company.

Stay tuned!!!