I have just taken on a new role with a company that want to set up a new QA Test team for the first time..ever. The problem is as there is no test team, a lot of the testing is being done by developers and BAs. As a result, every project within the company uses a diff testing methodology, mainly waterfall, with some new projects moving on to Agile. The company has over 30 diff project management, test and defect management tools across projects, thus one of my first things is to scale this time.

Herein lies my problem, the Agile projects use JIRA, (which I have never used so can evaluate from experience how good or bad it is) whilst some use QC. Cost is a big factor as well but my CTO wants the entire org. on QC. Please any ideas or suggestions as to the benefits on QC over JIRA or vice versa would be appreciated. Also, can QC be used efficiently for managing Agile projects?

Doggy,I was in a similar situation as you are in now. I moved out of development and started the QA group. While many of the developers wanted to use many different open source tools, I encourage them to wait until we had QC. We're using it across the board. Requirements, Test Cases, Defects, Automation.

We do have some developers who want to go Agile, HP has an agile template which can get you started running agile projects in QC.

QC allows you to create customize work flow, this comes in very handy when projects need to follow a certain process. While we do have standards that apply to all projects, some of my projects need customization.

QC is a great tool (I even used to manage their QA for almost 3 years!) but I have seen in more than a couple of places where it proved to complex to help in the agile process... specially developers and product owners who went crazy with the lack of flexibility of the tool (not to mention to cost!!!)

On the other hand JIRA is very good for agile but it lacks any decent testing functionality.

I work in Practitest now (and yes I am biased, but still) we have a number of agile-based customers using JIRA for their issue & task management (as part of their agile process) and managing their tests in our platform (specially since the addition of session-based testing support).

We are working on agile projects using QC as mail Testcase, management tool, Defect tracking mechanism.

We follow the regular sprint methodology as below:

1. Testcases are populated in Testplan as simple when every sprint starts. And the testcases for respective user stories are populated in respective modules/feature wise in mail project folder under testplan.

2. For each sprint we pull the testcases from testplan to testlab for execution within the sprint for execution to make sure as part of sprint deliverable those features/modules which are committed in the form of user stories are tested before the build is promoted.

3. Above 2 steps are Sprint QA's job --- who closely work with developers. This helps in nailing down the defects at early stage before the build is promoted to QA for official regression.

Note: for above 3 steps sprint QA's are responsible in logging the defects and make sure its fixed within sprint and verified and marked as locally verified(since its tested on Dev environment)

4. The above 3 steps continues until the target date is reached for the main build is promoted to QA environment for regression testing. (actual regression testing starts here.)

5. Once the build is promoted to QA environment then its total massage by the actual testers where manual / automation testing is carried out on the testcases populated by Sprint QA's.

6. Again here the regression team logs a defects the news ones if found or if the old sprint QA defects are reproducible the nthe locally verified defect would be reopened....etc

7. In due course daily defect review ensures the immediate / prioritizing the defects logged by regression team, that would be picked up in the on going sprints based on priority of defect.

8. The above 7 steps goes round until the release deadline is met.

Above all step 6, step 7 are important ones to plan testing cycles for the product.