What are the pros/cons of using a single TFS project to enter bugs?

We are using Team Foundation Server and we are trying to decide the best way to handle bug going forward. We are looking at two options but are leaning towards a single project.

1. Single QA Team where all bugs and test cases will reside in one TFS project owned by the QA team

2. All bugs and test cases will reside in the TFS开发者_C百科 project they are associated with.

Has anyone used a seperate single monolithic project for bugs? Is this supported out of the box by microsoft? Will reporting be affected? What are the reasons why we wouldn't want to have a single project?

---

The BIG advantage of TFS is that MS delivers a complete development environment from requirement / planning to deployment and test. The factory delivered default process templates are of real value to quickly startup your development effort. MS have put a lot of effort in the default process templates provided to you, and those templates are all project based (your option 2), meaning that they assume your items are entered and should be tracked on a development project basis. The bugs should be entered in the TFS project they are associated with.

Now, is it completely impossible to do all QA in a single project? Absolutely not! If you have (very) good reasons to do so, it can be realized. But, you will be fighting the system in some places, for example in the area of reporting and test impact analysis. I know from experience. In general, associating and guarantying traceability of your QA items with code and build items over TFS projects. AND, you will not be able to re-use the supplied proces templates. They will have to be customized to a large extend.

Hey, you have paid for the system, and it is not cheap! Try to use as much of possible for what you have paid for, including the process templates and the way of working from MS and community support, which will expect you to follow the MS guidelines.