Recently, our CEO, Gabe Buck, brought our entire office into our conference room for a Monday morning meeting. Among many other topics, he asked our entire team the following question, “What do you think differentiates a company like ours from other similar companies in our industry that separates us from the competition?” Many answers were thrown around such as tenacity, attention to detail, reliability, and all of the other answers you might hear that are tossed around in a motivational company meeting. One term that did catch my attention was adaptability.
Was it that I felt adaptability was more important that reliability or attention to detail? No. Was it that our company was not reliable or attentive to the needs of our customers? Absolutely not! Perhaps it was just true, that adaptability was something that our company has embraced and keeps us one step ahead of our competition.
With ClickPoint’s growing amount of business and customers, our development team and support team have had to put our heads together to adapt our current software engineering model to scale to the increasing number of customers and services that ClickPoint is expected to provide. This has meant putting our current process workflow for bug tracking, feature requests, change requests and testing under a microscope to assess what needed to be done.
One of the big areas that our team decided needed to be addressed was the process workflow for bug tracking. It was determined that although our previous workflow for bug tracking was sufficient for our ClickPoint team with a frequent release schedule, it was not sufficient for our LeadExec release schedule. Since LeadExec follows a less frequent release schedule, additional states needed to be added into our process workflow for bug tracking.
Additionally, our team felt that it would be a best practice to keep our process workflow for bug tracking consistent between projects, so the decision to change the ClickPoint workflow was made as well, in order to keep it uniform across all our projects.
Our team uses Team Foundation Server 2010 for all our version control and process management (bug tracking, issue tracking, testing, etc.). Team Foundation Server allows for extensive customization of process workflows by customizing Work Item Types and defining the relationships and transitions between them. Work Item Types in TFS are objects that can be tracked in Team Foundation Server (bugs, issues, change requests, etc.) which can be customized through XML to support the workflow of an organization. For more information on Work Item Types and how they can be customized, visit Work Item Types on Team Foundation Server.
One of the most important points to take note of with customizing work item types in Team Foundation Server is the ability to define a custom workflow for that work item type. This requires defining the allowed states and transitions within that work item type.
An example of the default bug work item can be seen below:
The default bug workflow shown above involves three states: Active, Resolved and Closed., which are represented by the circles. Additionally the arrows in between the states represent transitions. When a transition is made from one state to another it must be associated with a reason which can be seen as the text on the transition arrows.
The default bug workflow item is very basic and lacks important states that our team wished to utilize such as states for testing and states for giving project managers the ability to see the status of bugs. After several rounds of trial and error and modifications our team reached a process workflow for our bug tracking that was sufficient across all our projects.
Our modified bug work item process workflow:
Some important aspects of our modified process workflow are:
1) We have added 6 additional states
2) Transitions have been added to and from all states with the exception of “New”. This means each state can be revisited with the exception of “New.”
3) If a bug is determined to be unfixed or not ready for testing in the following states, it must return to “Active” and go back through the entire workflow to be closed. This was done to add redundancy to our testing plan, and so that additional details that might have been added in later states are not looked over.
Although we have essentially made the total number of possible paths a bug can follow through exponentially larger, we have also removed any “ambiguities” that a bug may have had following the default workflow. By removing the ambiguity from the workflow, we no longer are faced with asking questions such as the following, which would only pertain to the default workflow:
1) Is the bug brand new, and unseen to the developer?
2) Has the bug been verified by the developer yet?
3) Is the developer currently working on the bug?
4) Is the bug currently in testing?
5) If the bug is currently in testing, is it being tested in development, or on production?
6) If the bug failed, at which point in the testing did the bug fail?
7) Is the bug ready for production?
It was questions like these that were used to address the problems with our previous workflows, and were direct contributors to the modifications that were made to the process that we currently follow. With our modified process workflow in place, project managers, stakeholders, developers and our QA testing team can accurately track our bugs through the system. This has resulted in more efficient communication between our developers and our testing team, a higher rate of resolving bugs, and most importantly more stable code being deployed to production environments.