Defect Tracking Setup
Woo hoo, we finally appear to have a defect tracker coming soon. Seeing as we are getting a new defect tracker I have been charged with the Herculean task of setting up the new system. I have got between two and three weeks to setup the system and prepare training material before the final roll out.
Here is a little background information on the systems/products we need to track. We have a few Windows 32 applications, a few web based ASP applications, many internal web based applications. In addition we would also like to use it to track defects in our network and our physical hardware (sysadmin type requests).
My question is this: What are some common mistakes that you have seen been made when you setup these systems. If you could change the system that you have in place at your company what changes would you make? What portions of the system do you find really effective.
I am avoiding mentioning a product name, as I would like to keep this non-product specific. I am just trying to ensure that 1. We get the most effective use out of the product and 2. It has all the features we need and want to use.
Re: Defect Tracking Setup
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Beowulf:
My question is this: What are some common mistakes that you have seen been made when you setup these systems.<HR></BLOCKQUOTE>
The number one problem I always see is that there is not a "issue/defect tracking process" defined so that the tool works with it - rather than the tool forcing a process. This, in my experience, can cause a lot of problems.
Another major problem that I have seen: the tool is not flexible enough to allow you to change many aspects of how it works (such as different status values, changing e-mail notifications, automatic e-mailings of old defects that have not been changed, adding fields to forms, etc.) Part of a good tool, for me, is the ability to adapt it to our needs. When that is not possible I find that problems of limitation eventually crop up.
Concomitant with this I often see problems when there is not a good distinction between a "business issue" and a "behavioral issue" within the tool. To me a "behavioral issue" is either a "defect" or a "change request" whereas a "business issue" is more something that the business wants to track - but it is not related to the product so much as it is to the means by which the product is supported, maintained, etc. by the business.
Another problem: lack of defined priorities and severities. This goes back to having a defined process to a certain extent but even if a defined process is not in place, a system of priorities and/or severities should be.
Re: Defect Tracking Setup
Introducing fresh developers to the defect tracker and the process is a good starting point. I've attached a mail I sent to my team about the Defect TRacking process. See if it helps.