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)
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.
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.
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.
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.
The instructions are for Jira 3.x. The most recent version is 4.2. There are differences.
Step 5, "Custom Fields" has incorrect field names. The first instance of "Steps To Complete" should have the name "Actual Outcome".
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.
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
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.
所有这些问题类型都使用几乎标准的工作流程（为缺陷问题类型添加了 QA 确认步骤）和一些自定义字段。我们正在考虑使用单独的项目进行 QA 和 DEV 的替代方法，在这种情况下，我们可以使用版本而不是测试轮问题类型，但出于各种原因，我们决定反对它（如果您感兴趣，请告诉我，我可以详细说明） 。
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).
发布评论
评论（10）
尝试附加的 Kanoah 测试。
它是专为 JIRA 设计的综合测试管理解决方案。
访问：www.kanoah.com 网站了解更多信息
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
截至几周前，JIRA 最近实现了一项“功能”，该功能将为所有子任务克隆添加前缀“CLONE - ”。过去情况并非如此，如果您使用 JIRA Studio，则没有解决此问题的正确解决方案。因此，现在对我们来说效果很好的方法意味着我们需要使用专用工具。
即，如果您使用记录的方法，让 QA 周期包含一堆属于子任务类型的测试用例，那么当您为新的测试运行克隆 QA 周期时，所有测试用例都将前面加上单词“克隆-”。
就我而言，我现在将改用专用的测试管理工具。
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.
我们是 Atlassian Enterprise 和白金专家，虽然您可以自定义 JIRA 以用作基本测试管理工具，但您需要意识到它作为事件管理工具、任务管理工具和敏捷管理工具（使用 JIRA Agile 插件）表现出色）。
它从未被设计为测试用例管理工具，因此不提供您期望从纯测试管理工具获得的功能。诸如覆盖率报告、测试运行历史记录以及在一个地方管理手动和自动测试之类的事情。
我在 Catch Software (http://www.catchsoftware.com) 工作，我们构建了 Enterprise Tester，一个基于 Web 的具有市场领先的 JIRA 集成的测试管理工具。
此集成允许您从 JIRA 故事自动生成测试用例存根，从测试运行自动创建 JIRA 问题，并允许您将报告小工具放入 JIRA 或 Confluence 中，以便您的管理团队可以在一个地方查看所有指标。
您将获得一个与 JIRA 内部或 OnDemand 实例无缝集成（无需插件）的纯粹测试管理工具。
因此，检查您的测试需求，如果您需要测试基础知识，那么我们可以帮助您使用 JIRA 构建的解决方案，或者如果您需要更专业的测试管理工具，那么请随时查看 Enterprise Tester (http://www.enterprisetester.com)
问候
布莱斯
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
我推荐 Zephyr for JIRA，它是一个很棒的测试管理插件，与 JIRA 集成得很好。除了 Epic/用户故事管理之外，它还允许您维护测试用例套件和执行。
http://getzephyr.com/
我最近搬到的团队是新组建的，没有使用任何 TM工具本身（他们使用 JIRA 进行缺陷记录，使用 Excel 来维护 TC）——我看到了研究市场的机会，并开始寻找一种能够适应并在管理测试周期方面提供更大灵活性的工具。
Zephyr 干净地嵌入到 JIRA 屏幕中，其外观和外观也非常简洁。感觉和JIRA一模一样。因此，如果团队已经在使用 JIRA 进行问题/缺陷记录，那么学习 Zephyr 不会增加引入新工具的任何复杂性。
我在我们早期的程序中使用了 HP ALM（以及 QC，当它被如此称呼时！）。现在的驱动力是敏捷，我们发现 ALM 对于敏捷来说有点太麻烦了...我可能是错的，但是在 Zephyr/JIRA 之后我们选择继续使用 Zephyr 进行测试管理；）
在我的评估中，Zephyr JIRA 对我们来说运行得很好。我使用我所从事的其中一个 scrums 进行了 POC（这是一个包含 6 个不同 scrums 的大计划！），现在已经开始向其他团队推广，他们也喜欢这个想法和整个设置。定价点也没有那么高。
PS - 我们正在使用 Zephyr 作为 JIRA 服务器。
我希望这些信息有帮助。
干杯!
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!
我建议使用 QASymphony 的 qTest 测试用例管理工具。 JIRA 集成 是同类中最好的。您可以拉取所有开发工作，无论它们是 JIRA 故事、任务还是子任务（或自定义问题类型），并通过将测试用例与这些工具关联来构建对这些工作的可追溯性。最终允许您生成一键式报告。
您所有的手动测试用例都可以存储在那里，可以集中自动化工作，并且还有一个用于 UAT 和探索性测试的漂亮文档工具。该工具还在缺陷级别进行集成，允许测试人员将 JIRA 问题从测试执行直接提交到 JIRA 中，以便开发人员可以处理这些问题。本质上，JIRA 可以继续用于开发和规划工作，但所有测试工作都可以在 TCM 内解决。通过 JIRA 与企业可扩展工具的巧妙集成，整个 SDLC 流程更加简化。
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.
在过去的几周里，我尝试设置 Jira 进行测试用例管理，我可以提供我的经验的好处。上面引用的说明（自定义 JIRA 进行测试用例管理< /a>) 存在缺陷且不完整，因此请预先警告。 Atlassian 论坛中的 Jira 测试用例线程非常有帮助。
编辑：此链接已损坏，Atlassian 的“论坛”不再使用。使用此链接：自定义 Jira用于测试用例管理。
文档中还有更多的陷阱，因此在开始之前请确保您熟悉 Jira 工作流程和各种实体。我还建议仔细记笔记。
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.
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.
我们目前使用 TestLodge 测试用例工具 来管理我们的测试用例和需求，它与 Jira 集成以创建失败测试的票证案例。
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.
您可以轻松地将需求存储为顶级 JIRA 问题；许多使用“用户故事”方法记录需求的敏捷项目都这样做。我也会将测试用例存储为顶级 JIRA 问题，并将它们链接到与其相关的需求，而不是将它们作为需求的子任务；例如，如果一个测试用例可以应用于多个需求，这就提供了灵活性。
如果您将所有测试用例都作为单独的 JIRA 问题，则可以在每次进行测试运行时为每个用例创建一个测试报告作为子任务。为了简单起见，您确实需要 JIRA 中的批量克隆工具，您可以在其中克隆想要再次运行的所有测试报告，但我无法找到如何在 JIRA 中执行此操作。
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.
在我们的团队中，我们有一个 QA 部门，一直在使用 QC（并且仍在某些项目中使用它），并且我们正在使用这样的问题组织：
顶级
对于
所有这些问题类型都使用几乎标准的工作流程（为缺陷问题类型添加了 QA 确认步骤）和一些自定义字段。我们正在考虑使用单独的项目进行 QA 和 DEV 的替代方法，在这种情况下，我们可以使用版本而不是测试轮问题类型，但出于各种原因，我们决定反对它（如果您感兴趣，请告诉我，我可以详细说明） 。
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
Subtasks
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).
这可能是你想要的：
http://blogs.atlassian.com/jira/bonfire/
it may be what you want:
http://blogs.atlassian.com/jira/bonfire/