Jira as Test Case Management Tool [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

Closed 7 years ago.

Improve this 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 hav开发者_开发知识库e:

• 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

---

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.

---

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.

---

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.

---

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

---

it may be what you want:

http://blogs.atlassian.com/jira/bonfire/

---

Try the add-on Kanoah Tests.

It is a comprehensive test management solution especially designed for JIRA.

Visit: www.kanoah.com website for more information

---

As of a few weeks ago, JIRA recently implemented a "feature" that will prefix all subtask clones with the word "CLONE - ". This didn't use to be the case, and if you're using JIRA Studio, there's not a proper solution around this problem. So what was working well for us now means we need to use a dedicated tool.

i.e. If you're using the documented approach of having QA Cycles that contain a bunch of Test Cases that are of a subtask type, then whenenver you clone a QA cycle for a new test run, all of your test cases will be prepended with the word "CLONE - ".

In my case, I'll be switching to a dedicated test management tool now.

---

We are Atlassian Enterprise and Platinum Experts and while you can customize JIRA to be used as a basic test management tool, you need to realize that it excels as a incident management tool, a task management tool and an agile management tool (with JIRA Agile plugin).

It was never designed to be a test case management tool and as such doesn't provide functionality that you would expect from a pure test management tool. Things like coverage reporting, test run history and managing manual and automated testing in one place.

I work for Catch Software (http://www.catchsoftware.com), we built Enterprise Tester, a web based test management tool that has the market leading JIRA integration.

This integration allows you to auto generate test case stubs from JIRA stories, automatically create JIRA issues from test runs and allows you to place report gadgets into JIRA or Confluence so your management team can see all metrics in one place.

You get a pure test management tool that is seamlessly integrated (no plugin required) with your JIRA in-house or OnDemand instance.

So check your testing needs and if you need testing basics then we can assist you with a JIRA built solution or if you need a more specialized test management tool then feel free to check out Enterprise Tester (http://www.enterprisetester.com)

Regards Bryce

---

I would recommend Zephyr for JIRA which is a great test management add-on that integrates well with JIRA. It allows you to maintain test case suites and executions in addition to Epic/User Story management.

http://getzephyr.com/

The team I moved to recently had been newly setup and hadn't been using any TM tool as such (they used JIRA for defect logging and Excel to maintain TCs) - I saw an opportunity to research the market and started looking for a tool that could fit in and provide more flexibility in managing Test Cycles.

Zephyr is cleanly embedded within JIRA screens and the look & feel is exactly like JIRA's. Hence, if the team is already using JIRA for issue/defect logging, learning Zephyr doesn't add any complexity of introducing a new tool to the mix.

I have used HP ALM (and QC when it was called so!) for our earlier programs. Now that the drive is to go agile, we found ALM to be a bit too cumbersome for Agile... I might be wrong there, but after Zephyr/JIRA we opted to stay with Zephyr for Test management ;)

In my evaluation, Zephyr for JIRA is working quite well for us. I did a POC using one of the scrums that I work on (its a big program of 6 different scrums!) and have now started rolling out to other teams and they also liked the idea and the whole setup. The pricing point is also not that high.

P.S. - We are using Zephyr for JIRA Server.

I hope this information helps.

Cheers!

---

I would suggest the qTest Test Case Management tool by QASymphony. The JIRA integration is best in class. You can pull over all of the development efforts, whether they are JIRA stories, tasks, or sub tasks (or custom issue types) and build out traceability to those through the tool by associating test cases to them. Ultimately allowing you to generate one-click reports.

All your manual test cases can be stored there, automation efforts can be centralized, and there is also a nifty documentation tool for UAT and exploratory testing. The tool also integrates at the defect level, allowing testers to submit JIRA issues directly into JIRA from test executions so they can be worked on by development. Essentially, JIRA can continued to be used for dev and planning efforts but all the testing efforts can be tackled within the TCM. With this slick JIRA integration to an enterprise scale-able tool, the whole SDLC process is more streamlined.