当开始一个新的软件开发项目时，许多公司选择使用Jira作为他们的项目跟踪工具。如果你正在读这篇文章，很可能你对它很熟悉。虽然Jira可能是跟踪进度的有用工具，但最好有最佳实践来发挥最大的作用。了解如何优化你的Jira QA工作流程下面。

Jira QA工作流程

Jira板列类型不是一刀切的方法。不同的团队可能会发现不同的约定适用于他们。(要了解更多，请参阅我们的文章敏捷QA过程)。但是，下面的选项显示了几乎所有Jira测试工作流中遵循的典型列范围。

以下是一些Jira专栏的例子:

第一组-“所有的列!”方法

待定事项/已准备好开发/正在进行/已准备好登台/已准备好测试/正在测试/重新开放/已准备好生产/正在生产/已在生产中测试/已完成

第二组:基本方法

新的/正在进行中/准备测试/完成

只要每一列都能有效地发挥作用，倾向于多列的一边通常是有帮助的。每个列越具体，团队中的任何人就越容易通过快速浏览看板板立即获得高级状态报告。

如果您比较上面的组，您可以看到组1中的选项如何更清楚地了解任务的进展情况，而组2的方法则更简单。

虽然这看起来有些难以承受，但记住可以通过快速拖动鼠标在列之间移动票据是有帮助的。只要团队遵守更新票据状态的纪律，详细的列可以成为Jira QA过程的巨大资产。

Jira票域

与工作流程一样，与Jira票据字段相关的需求在不同的项目中可能有很大的差异。但是，每个项目在理想情况下至少应该有以下票务字段:

• 总结(供输入门票名称)
• 描述(包括重现步骤等细节，以及更详细的功能或错误分解)
• 问题类型(漏洞，功能，故事，史诗等)。通常情况下，项目经理负责创建功能、故事和史诗，而QA负责创建错误报告票)
• 受让人(如果需要，项目经理或其他一线审核人员可以是默认的Jira受让人)
• 优先级(低，中，高，严重，阻塞)
• 标签(该字段允许简单的自定义票证分组)
• 环境(例如开发、登台或生产，以及识别错误的特定设备型号、操作系统和/或浏览器。在我们的指南中了解更多跨浏览器测试）

此外，如果被测试的产品涉及手机应用程序或其他类型的版本控制软件，应该有字段用于版本(例如，1.52)和组件(例如iOS、Android、Web或API)。

创建尽可能多的自定义字段是很诱人的。但是需要记住的是，要求太多会大大减慢Jira QA过程。当涉及到“功能”票时，项目或产品经理通常不需要一次创建几十个。但对于QA来说，票证制作是另一种情况。

在一个主要的回合回归测试在美国，QA在一天内制作20多个bug罚单的情况并非闻所未闻。当有人不得不停下来思考在不必要的或无关的字段上写些什么时，额外的时间和分心最终会降低工作效率。关键是在有足够多的详细/有用的字段而不过分之间找到平衡。

缺陷优先级

鼓励QA为bug设置初始优先级，这对整个团队都是有益的。毕竟，QA测试人员擅长的是用户体验．因此，它们通常是你评估bug对客户/用户的重要性的最佳选择。(不知道如何划分优先级?看看我们的指南吧:如何优先解决Bug)。

当然，考虑到总体业务目标，产品经理以后可能会改变优先级。但是将初始过滤器作为指导可以帮助所有级别的团队成员更快地审查重要的错误。QA可能并不总是100%与产品经理保持一致。但很有可能QA标签上的门票会是非常重要的，需要尽快审查。

Jira积压整理

如果Urban Dictionary有一个“技术”的部分，“backlog”的定义可能是这样的:

一个非紧急车票永远消失的黑洞

但事情不应该是这样的!敏捷的短语“backlog梳理”可能会让人联想到一个长时间、无聊的电话或会议，在这个会议上几乎没有什么事情要做。但是，如果一个团队养成了定期处理待办事项的习惯，这个过程就会变得轻松——甚至相当令人满意。

通常情况下，一个公司的Jira积压主要由被认为是“中等”或更低的错误票组成。虽然很容易觉得小问题不总是需要处理，但它们真的可以累积起来。“被一千张纸割伤致死”会像一个重大漏洞一样让用户离开。

那么，如果你积压了越来越多的票，而且似乎从来没有进入冲刺阶段，你该怎么办?幸运的是，有几种补救措施:

1. 定期对backlog bug进行冲刺。你不需要每个月都做这件事——想象一下把其他优先事项放在一边是很伤脑筋的。但是，如果距离团队上一次处理积压工作已经过去了6个月，那么可能是时候考虑一下了。
2. 承诺在每个sprint中至少引入两个backlog错误，即使它们很小。这可能不会降低您的总积压票据数量。毕竟，QA可能会在sprint中添加两个以上的新backlog错误。但至少你会有动力，而且决定买哪张票的过程将有助于确保积压中的任何东西都不会被完全遗忘。更频繁(但时间更短)的backlog梳理会议也不那么乏味。

Jira估计

大多数团队都会让开发人员提供Jira估算(以粗略时间或故事点的形式)。然而，QA经常被排除在洗牌之外。有些测试人员可能会为此感到高兴，因为被要求提供评估可能会令人生畏。但另一种情况是，非QA人员通常会对QA所需的时间做出不准确的假设。

通过让QA参与评估，项目经理可以确保sprint范围和时间线没有风险。至少，让QA团队来运行你的假设是个好主意。如果市场营销部门已经开始为某个功能的发布日期进行宣传，但最终却推迟了，那么公司的情况会比他们将发布日期推迟几天糟糕得多之前公告。(当被要求提供估算时，不确定从哪里开始?请看我们的指南:QA测试和评估技术)。

自动化测试和Jira

为自动化测试为了有效，脚本需要编写在已完成的特性上。如果QA为一个仍在进行中的特性创建了自动化，那么许多(如果不是全部的话)方面将需要稍后进行更新。因此，实现自动化测试的最有效的方法之一是让自动测试器在一个sprint中工作。也就是说，从前一个sprint自动化完成的票据。

当敏捷scrum团队使用这种策略时，管理自动化进程乍听起来可能很困难。如果票不在当前的sprint中，团队将如何跟踪自动程序的进度?通过遵循一些简单的规则，这个过程实际上可以更有效。

在Sprint计划在会议中，自动化测试人员可以基于前一个sprint的特性创建Jira票据。为了避免其他团队成员的混淆，他们可以简单地将这些标记为自动化票。一旦将这些卡片添加到sprint中，Jira的工作流程就与开发人员的工作流程完全相同。

作为一个额外的好处，这个过程还允许手动和自动QA为了测试相同的功能而不互相侵犯。如果手动QA测试人员有时间写就更好了测试用例在之前的冲刺中。在这种情况下，自动化器还可以通过使用测试用例作为自动化内容的指南来节省时间。

Jira评论

吉拉票的评论区是传说的东西。好吧，这可能有点过分了。但一个团队的评论过程可以成就或毁掉他们的Jira体验。相关的、详细的票证注释对于QA在功能准备好测试时进行审查非常有帮助。但有一些最佳做法要记住:

如果注释不能明确地帮助工作流中的任何人，可以在其他地方讨论它。

当测试时间很紧时(通常是这种情况!)，a质量工程师阅读100多条评论是需要时间的，这是不可能的。相反，使用电子邮件、Slack或任何其他平台来讨论某个功能的初步细节是个好主意。然后您可以返回并使用最终需求更新票据描述。

标签!

如果您正在添加关于票据的重要细节的评论，那么在评论中标记QA测试人员是很重要的。即使票还没有准备好进行QA，这也是正确的。这将帮助他们为正确地测试做好准备，或者使他们能够提出方法的潜在问题。QA甚至可能已经开始编写测试用例了，所以尽早获得额外的信息可以改变游戏规则。

决定一个顺序，并坚持下去。

有些团队更喜欢将Jira注释设置为升序显示。还有# teamdescent(这个标签可能短期内不会在Twitter上流行)。无论你做出何种选择，都要确保整个团队都知道。这可能听起来微不足道，但却能产生真正的影响。很容易看到一个评论列表，并假设最近的评论在顶部(反之亦然)。按照错误的假设行事可能会导致基于过时信息的QA测试。

作为一个团队，决定QA是否可以重新打开带有详细描述bug的注释的特性票。

另一种选择是让bug 100%地单独出现。能够添加带有错误详细信息的注释可以节省时间。但是bug可能会在这样的混乱中丢失。此外，如果开发人员的修复尝试不成功——或者存在多个错误——来回注释的列表很快就会变得难以处理。

Jira子任务

子任务是另一个每个人都有自己的方法的领域。当一个bug与特性票相关时，一些团队有使用子任务的规则。例如，如果QA测试了一个概要文件部分，并发现名称字段被破坏了，他们可能会在概要文件特性文件下创建这个错误记录作为子任务。从理论上讲，这是完全合理的。但在实践中，由于以下原因，它可能导致不那么敏捷的Jira过程:

• 当产品/项目经理检查主板时，子任务并不总是清晰可见。
• 有时，即使有一些小错误，业务部门也会决定发布该特性。在这种情况下，Jira用户将希望能够将功能票据标记为“完成”，并单独跟踪相关的错误。

另一方面，如果一个bug与某个特性有关，您将希望确保很容易跟踪这种关联。对此，最简单的解决方案是创建单独的bug票据，但将它们标记为“链接”、“由”或任何形式的与特性票据的Jira关系。这样，你仍然可以从功能票证中看到相关的bug列表——而不会对整个板视图/可用性产生负面影响。

分配Jira票

分配门票本身就很容易。但每个人都会时不时地犯错。以下是一些可能出现的关于受让人的问题，以及可能的解决方案:

• 当有多个QA测试人员时，开发人员不确定将测试票分配给谁。这个问题可以通过几种方式解决。首先，在这种情况下，要有一个可靠的受让人。这个人可能是QA主管，他将决定如何分配工作，也可能是项目经理。(如果有品质经理，这是另一个不错的选择。)另一种方法是将票分配给一个人，但在票注释中标记其他人。
• QA测试人员不确定应该将bug票分配给哪个开发人员。这通常是在项目的早期阶段，或者在同一个组件中有多个开发人员(例如，三个Android开发人员)时出现的问题。如果问题是QA(或开发人员)是项目的新手，解决方案是提供一个位于中心位置的团队成员及其角色列表。如果问题是在同一区域有多个开发人员，那么可以采用与上述问题相同的方式来解决——设置一个负责进一步审查票据的指定人员。这个人可以是项目经理，也可以是首席开发人员。
• 团队成员改变一个票的状态(例如:从“正在进行中”到“准备测试”)而没有更新受让人。相关人员最终可能会注意到看板板的更新。但是如果他们收到了受让人的电子邮件通知，他们就能更快地开始工作。每个人都会犯错，但解决方法是不断提醒犯错的人。

另一个最佳实践是将QA添加到任何相关门票的“观察者”列表中。这样，即使有人忘记更新标签或受让人，他们也会看到更新。

优化QA的Jira

当你刚开始的时候，不管你是什么角色，Jira都会觉得不必要的复杂。但是如果你优化你的Jira测试工作流程并遵循这些最佳实践，你将为一个更有效的过程、更快乐的团队和更好的最终产品奠定基础。

把你的Jira QA过程到下一个水平

你的QA过程需要咨询?点击我们的点播QA测试服务．我们也做敏捷咨询，可以帮助优化您的Jira QA过程。