Option 2: DIY converting your bug tracking system
This is the third in a series about upgrading your outdated bug tracking & QA systems. The first article went through the pros and cons of upgrading, the second explained your first option. Here is the 2nd option.
Option 2: Do it yourself
This involves allocating a team member to research the best option, designing it and implementing it. This is what I did, as newly appointed QA manager, working at Trimble, several years ago.
I polled all other divisions within Trimble to find out how they were tracking bugs and also what concepts were important to them in a new bug tracking system. I found that every division was tracking bugs differently, based on their specific histories, but they all had unmet needs. I took this combined list of needs and used this criteria to choose the best bug tracking system.
The system I chose was JIRA from Atlassian. It met all my criteria including price. I first implemented JIRA for just one product and one dev team, at the beginning of a release cycle. I used this to evolve the best workflow and find out how to tune JIRA and plumb its limits.
Once the dev team on this project were happy ( a major consideration, because other devs would only accept such a change to their working environment, if the first devs said it was a change for the better), then I added more and more products, until finally the whole division (Mapping and GIS - MGIS) in Trimble was using the same system. Then developers, testers and managers could move from product to product, all the time in the same consistent Information System.
This was very successful.
Other Trimble divisions came to a point where they wanted to move to a better bug tracking system. Their productivity was being affected by a poor bug tracking system.
They looked at the MGIS implementation and gradually more and more divisions adopted JIRA.
Each division was running off its own instance, to enable divisional control of this important system.
Of course, some projects spanned several divisions. How to handle this complexity? Atlassian continues to support and expand JIRA functionality, especially in the enterprise space. JIRA has been engineered to support multi-division projects easily via issue linking.
Based on my experience with JIRA, I am a fan, and now base much of my consulting around leveraging JIRA.
Option 2 is certainly a viable option for you. I have done it. It may not be your most cost-effective option however because that learning curve requires investment, an investment which may never be re-used in your organisation.
