I'd like to thank everyone in advance for looking at this. My company has run into a quandry and any advice or suggestions would be greatly appreciated!
We have a project going on which has three main components to it. It is a typical N-Tier architecture, written in Java, using SOA, and Cobol/Mainframe back end.
The tiers are:
1) Front End (User Interface Application)
The development teams are grouped as above. But the Testing Team is just one group.
Currently we have created one project in Quality Center to put our test cases & track defects.
Development wants separate projects in Quality Center to track defects for UI, defects for Middleware & defects for the Database.
But we don't have separate test scripts for testing MiddleWare or the Database. The majority of the testing will be through the Front End.
Also there are multiple other applications for which we want to start tracking defects with Quality Center. These applications will also be interfacing with the same MiddleWare & the same databases.
Some Questions we have:
1) Is it a good idea to create multiple projects in Quality Center just to track defects for each application separately?
2) Is there a way to link defects between projects as the Database & Middleware will pretty much affect every application which we have.
3) Or would you recommend tracking all the defects in one project?
We've looked into customizing Quality Center's abilities with our own VBScript code, and have had little time to check this route out for feasability system-wide.
Again, any information or suggestions would be greatly appreciated!
Well you be the judge and apply logic to all your questions. As they say, the way to solving a problem is to ask the right questions.. and you are certainly on the right track.
Some things you can consider while answering these questions can be the level of differentiation between your developer teams, and whether you're going to have separate teams testing the application.
It could be a pain when you have to cycle through defects belonging to different teams and at the same time a pain when your team have to switch between different projects to log defects for different teams.
In my opinion use QC the way it is designed to. i.e., put all those apps in one project that have their one requirement specs, so that you have E2E mapping of them in one place.
My suggestion would be to maintain them in one project. Add a custom required field to the defects indicating whether it's a defect in the UI, the middleware, or the database. Then your developers can sign in and filter their defects based on that column. They will only ever see the defects that matter to them, if that's what they want.
This has the added advantage of providing the appropriate flexibility should one of your testers, while creating the defect, misdiagnose the source of the problem; you won't have to rebuild the defect in a different project, but will just change the appropriate field. (I don't know how your testers are, but some of ours are the kind who couldn't get hired in the fast-food industry, and they're not always real good about setting fields right the first time through.)