Jira as Test Case Management Tool

Question

Hello,

I have reviewed several test case management solutions available for Jira such as:

• http://www.testandtry.com/2009/07/01/test-case-management-in-jira-1/
• http://confluence.atlassian.com/display/CONFEVAL/Customise+JIRA+For+Test+Case+Management

I was wondering if it is possible to expand this test case management solution even more. I am looking for a Jira solution to have:

• Requirements
• Test Cases (which go under Requirements)
• Test Reports (which go under Test Cases)

The links posted above only ignore the "Requirements" part and focus only on Test Cases and Test Reports. Every Test Case Management tool I have used before has these features like HP QualityCenter.

Is it possible to achieve this in Jira?

TIA

Answer 1

You could easily store the requirements as top level JIRA issues; many agile projects that use the "user story" method of documenting requirements do this. I would store the test cases as top level JIRA issues as well and link them to the requirements they relate to, rather than making them subtasks of the requirements; this gives flexibility if a test case can apply to more than one requirement, for example.

If you have all your test cases as individual JIRA issues, you can create a test report as a subtask for each case every time you do a test run. To make that straightforward, you really need a bulk clone facility in JIRA where you can clone all the test reports that you want to run again, but I haven't been able to find out how to do that in JIRA.

Answer 2

In our team we have a QA department that has been using QC (and is still using it for some projects) and we are using an issue organization like this:

Top Level

• Requirement - capturing the actual user story. Created by BA, assigned to DEV lead, owned by BA.
• Incident - capturing a problem that happened with a production system. Created by BA/operations, assigned to QA, owned by BA.
• Binary Package - created and owned by Deployment team to track the lifecycle of each binary package produced. So far we are tracking deployments and change tasks as comments, but if we wanted to be more fine-grained we could have used separate child issues too.
• Test Round - top-level - usually for reporting purposes you want to separate the artifacts produced by each test run/phase of your QA team. Test run issues are containers for defects.
• Test Case - created, assigned and owned by QA manager. Here you have choice:
  • defined as top-level issue - you can link it to requirement, multiple requirements or create standalone (e.g. to capture regression scenario not tracked in JIRA.
  • defined as subtask - limits you to one parent, but you can still link related requirements/incidents. The big difference is that this forces you to track the reason for each testcase in JIRA.
  • for many projects we still keep the test cases in QC and only track the defects in JIRA.

Subtasks

• Development (under Requirement) - created by DEV lead, assigned to DEV team, owned by DEV team. Describing a piece of work or part of use case that is estimated and assigned to a single person.
• Defect (under Test-Round or Incident), created by QA/DEV, assigned to DEV Team, owned by QA. Describing the isolated defect. For most purposes it's treated in the same way as Development, except that it has to be confirmed and closed by QA.
• Test Run - documenting the results of a single test run. We still find QC to be a better tool for this, though JIRA can be a workable too, especially if we write a few plugins.

All these issue types use almost standard workflow (with added QA-Confirmation step for Defect issue type) and a few custom fields. We were considering alternative approach of using separate projects for QA and DEV, in which case we could have used versions instead of Test Round issue type, but for various reasons we decided against it (let me know if you are interested, I can elaborate).