| || |
How do you keep track of troubleshooting cases?
I've been put in charge of improving our process for tracking cases on our website that don't yet qualify as bugs. Examples of this are reports from individual users that have been escalated from customer support, errors in logfiles that are not yet understood, questions from the sales team or potential customers about how something on the site works, etc. Basically, work items where someone on the QA team needs to do some research then get back to someone or write up a bug.
Customer support does not currently have a tracking system that is sufficient for this so I'd probably have to build or buy something. Our bug tracking system is homebuilt and we have built tools for managing users in production so we could add capabilities to those if it seems like the best course of action. There are advantages and disadvantages to each of those locations. If it lives in production it has access to user data and logfiles but is an additional place for QA to have to check every day and is not linked to the database. If it lives in the QA database it is more convenient to reach but is not tied into the data.
How are others dealing with these types of reports? Do you use something built into a support tracking system, in your bug database, or something else entirely? Any successes or failures to share?
Re: How do you keep track of troubleshooting cases?
We do have it in the same database as the bugs. Although it are other people that are following-up on these kind of 'requests'.
The advantage is that you have one entry point to check on what still needs to be done (and thus planned) for the application.
If you have both in the same database it is important to have good reporting possibilities and an easy assignment process, i.e. who needs to follow-up what requests.