I am a Test Manager, infact I am the only one. We have bug tracking software, where we enter bugs, I montior this. At present it is suggested we enter our change requests in this system too. personally I think this will bog the system down, and secondly I don't want to bog myself down sifting through CR's and Bugs when I have test plans and test scripts to write. We have suggested a replicar system of the bug tracking and we keep this for CR's alone - my point is whats the point of that, we need to have someone who makes a decision on whether a CR goes ahead or not......any ideas on this subject or are there any guidelines on process..?
Change requests bog a system down regardless of a tool. I would recommend using the same tool for both. I would tend to believe that you can create/assign a category/priority/severity, etc for these requests - and that the repository is a database that provides you with all kinds of querying capabilities to isolate change requests and manage them.
More tools = more overhead and accompanying costs!
If you do not have process, then a tool will not be of benefit in either case.
Utilize your bug tracking system! That's what it's there for. Having Change Requests under a different heading within your tracking system will allow you to sort them out if those are all you want to see. Having all notes regarding one project within the same database ensures that nothing will be missed.
My project managers and department heads all have access to my databases (although all they can do is add and modify ). Should someone find a bug, have a question or have a comment from the client - I'll never lose track of them.
I highly recommend that you use your tracking software and build your process around it!
I agree with those suggesting you use the same tool but make sure that CRs have a unique field value that makes it easy to separate them for reporting and measuring purposes. One benefit is that code changes then only need to be tracked against one database instead of two.
Software Testing (n): 1. The art of trying to increase your confidence in a piece of software by finding everything that is wrong with it.
I'm glad everyone concurs. For efficiency and effectiveness you should track both bugs and change requests in the same database. ID the difference between the two using a field. Often a bug will become a change request or a change request will turn into a bug. Tracking them in separate databases would be a mess.
IMO a bug database should be thought of as a "work to complete before we ship" list. It doesn't matter if it's a bug or a change request, it's something that a programmer and tester need to spend time on before the product is released. Remember, you'll need to write test cases and perform testing on those changes!
As a manager I look at how many active/open entries there are. That tells me how much work there is to do and gives me an idea if we're on schedule.