Jira as Test Case Management Tool [closed]

Question

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

Having spent the past few weeks trying to set up Jira for testcase management, I can offer the benefit of my experience. The instructions referenced above (Customize JIRA For Test Case Management) are buggy and incomplete, so be forewarned. The Jira Test Case thread in the Atlassian forums is very helpful.

Edit: This link is broken, Atlassian's "Forums" are no longer in use. Use this link: Customize Jira for Test Case Management.

1. The instructions are for Jira 3.x. The most recent version is 4.2. There are differences.
2. Step 5, "Custom Fields" has incorrect field names. The first instance of "Steps To Complete" should have the name "Actual Outcome".
3. Step 8.2 requires that you assign the "Create Issue" step to the "Create Test Case Screen". Since you haven't created any workflows or steps this will be difficult. You will need to return to this step after you finish Step 9.
4. Step 9, "Custom Workflow" is deeply confusing. You are told to create new states twice (Step 9.1 and Step 9.4/5). In Step 9.1 you want to create new "Statuses", not "States". In Step 9.4/5 you want to create new "Steps", not "States". Step
5. Creating new Steps requires that new Transitions be created. Each Transition will link two steps. You will need to create the transitions as you create the steps.

There are considerably more gotchas in the docs, so make sure you're comfortable with Jira workflows and the various entities before you begin. I also recommend keeping careful notes.

Answer 2

We currently use TestLodge test case tool to manage our test cases and requirements and it integrates with Jira to create ticekts of failed test cases.

Answer 3

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 4

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).