在启动新的软件开发项目时,许多公司选择使用JIRA作为其项目跟踪工具。如果您正在阅读本文,那么您很可能会熟悉它。虽然Jira可以成为跟踪进度的有用工具,但拥有最佳实践来打包最多的方法是有益的。在下面了解如何优化JIRA QA工作流程。

Jira QA工作流程

JIRA板列类型并不是一种适合所有方法。不同的团队可能会发现不同的惯例对他们有用。(要了解更多信息,请参阅我们的文章敏捷质量检查过程

以下是JIRA列的一些示例:

第1组 - “所有专栏!”方法

积压 /准备开发 /正在进行中 /准备登台 /准备测试 /准备 /重新开放 /准备生产 /生产 /生产 /测试

Jira QA Workflow(计算机屏幕的图标,带有标题为“ to do”,“ do”和“ dook”的列的图标第2组 - 基本方法

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

只要每一列都有一个有效的目的,倾向于更多列的侧面通常会有所帮助。每一列越具体,团队中的任何人就越容易立即获得高级状态报告,可以快速浏览看板董事会。

如果比较上面的组,您可以看到第1组中的选项如何提供更清晰的视图,即沿任务的距离,而不是第2组的裸露骨头方法。

虽然这似乎令人不知所措,但记住可以快速拖动鼠标之间的票面门票。只要团队对更新机票状态有纪律处分,详细的列可能是您的JIRA QA流程的巨大资产。

吉拉门票场

与工作流一样,与JIRA票务领域有关的需求可能因项目而异。但是,每个项目理想情况下应至少拥有以下门票字段:

  • 概括(用于输入票证)
  • 描述(包括诸如复制步骤之类的详细信息,以及功能或错误的更详细的细分)
  • 问题类型(错误,功能,故事,史诗等。通常,项目经理会创建功能,故事和史诗,而QA创建错误报告门票)
  • 受让人(如果需要,项目经理或其他前线审阅者可以是默认的JIRA受让人)
  • 优先(低,中,高,关键,阻滞剂)
  • 标签(该字段允许轻松自定义门票分组)
  • 环境(例如,开发,分期或生产以及特定的设备模型,OS和/或浏览器已确定错误。在我们的指南中了解更多信息交叉浏览器测试

此外,如果被测试的产品涉及移动应用或其他类型的版本的软件,应该有针对版本(例如,1.52)和零件(例如iOS,Android,Web或API)。

JIRA机票字段和工作流(包括项目,类型,摘要和说明)创建尽可能多的自定义字段可能很诱人。但是,请记住,需要太多的人可以大大减慢JIRA QA过程。当涉及“功能”门票时,项目或产品经理通常不必一次创建数十个。但是对于QA来说,创建门票是另一个球游戏。

在主要的一轮回归测试,QA一天创建20多张错误票并非闻所未闻。当某人不得不停下来思考要为不必要或无关的领域投入的内容时,额外的时间和干扰最终会降低生产力。在没有过多的情况下,在没有足够的字段进行详细/有用的情况下找到平衡是关键。

错误优先级

鼓励质量保证设定错误的初始优先级可能对整个团队有益。毕竟,QA测试人员专门研究用户体验。结果,它们通常是估计错误对您的客户/用户的重要意义的最佳选择。(不确定如何优先考虑?查看我们的指南:如何优先考虑错误修复

当然,考虑到总体业务目标,产品经理可能会以后更改优先级。但是,将初始过滤器作为指南可以帮助各级团队成员更快地审查重要的错误。质量保证可能并不总是与产品经理保持一致的100%。但是,很可能会尽快审查票务标签QA QA标签很重要。

Jira积压梳理

如果城市词典有一个“技术”部分,那么“积压”的定义可能会像:

一个黑洞,非紧急门票因永恒而消失

但这不必这样!敏捷的短语“积压修饰”可能会想到一个长时间无聊的电话或会议的图像,几乎没有完成。但是,如果团队定期养成养育积压的习惯,那么这个过程可能会无痛,甚至令人满意。

Jira Sprint板显示门票工作流程和专栏通常,公司的JIRA积压主要由被认为是“中等”或更低的错误票组成。虽然很容易感觉到小问题并不总是需要处理,但它们确实可以加起来。“剪掉一千张纸的死亡”可以使用户与一个主要的错误一样多。

那么,如果您拥有不断增长的门票似乎从未进入冲刺,该怎么办?幸运的是,有几种补救措施:

  1. 有定期用于积压错误的冲刺。您不需要每个月这样做 - 想象将其他优先事项搁置可能会令人不安。但是,如果该团队上次在积压列表中陷入困境已经六个月了,那么可能是时候考虑了。
  2. 承诺在每次冲刺中至少要拉出两个积压错误,即使它们很小。这可能不会使您的总体积压票号降低。毕竟,在冲刺期间,质量保证可能会增加两个以上的新积压错误。但是至少您会有动力,决定要拉的门票的过程将有助于确保积压中的任何东西都完全被遗忘了。拥有更频繁(但更短的)积压美容会议也是不那么乏味的。

JIRA估计

大多数团队都会让开发人员提供JIRA估算值(以艰难的时间或故事点的形式)。但是,质量值质量检查很常见。一些测试人员可能会为此感到高兴,因为被要求提供估计可能令人生畏。但是,替代方案通常是一个非QA的人,通常对质量检查质量检查所需的时间不准确。

通过要求质量保险公司对估计进行权衡,项目经理可以确保Sprint范围和时间表没有危险。至少,最好由QA团队进行假设是一个好主意。如果营销开始宣传最终迟到的功能的发布日期,那么该公司看起来比将发布日期推迟几天要糟得多。这个通告。(不确定在被要求提供估算时从哪里开始?请参阅我们的指南:质量检查测试估计技术

自动测试和JIRA

为了自动测试为了有效,需要在完成的功能上编写脚本。如果QA为仍在进行的功能创建自动化,则需要以后更新许多(如果不是全部)方面。因此,实施自动化测试的最有效的方法之一是让Automator在门票上进行一次冲刺。也就是说,要自动化以前的Sprint完成的门票。

质量检查工作流(带有文件夹和JIRA票证图标的计算机)当敏捷的Scrum团队使用此策略时,管理自动化进度起初听起来很困难。如果门票不在当前的冲刺中,团队将如何跟踪自动车手的进度?通过遵循一些简单的规则,该过程实际上可以更有效。

在a之前冲刺计划开会,自动化测试仪可以根据上一秒的功能创建JIRA门票。为了避免其他团队成员的混淆,他们可以简单地将这些标签标记为自动化门票。一旦将这些卡添加到冲刺中,JIRA工作流就与开发人员的工作流完全相同。

作为另一个好处,此过程还允许手册和自动质量检查测试相同的功能,而无需踩到彼此的脚趾。如果手册QA测试仪有时间写作,那就更好了测试用例在上一个冲刺期间。在这种情况下,自动机器人还可以通过使用测试用例作为自动化的指南来节省时间。

吉拉评论

JIRA票的评论部分是传奇的东西。好的,那可能有点远。但是团队的评论过程可以使他们的JIRA经历或破坏他们的经验。相关,详细的票务评论对于QA可以进行测试时,对质量保险公司进行审查可能非常有帮助。但是有一些最佳实践要记住:

如果评论不会明确帮助任何人降低工作流程,请在其他地方讨论。

当测试时间轴紧密(通常是这种情况!)时,质量检查工程师不得不阅读100多个评论将需要一些时间就不存在。相反,使用电子邮件,Slack或任何其他平台讨论功能的暂定细节是一个好主意。然后,您可以回来使用最终要求更新票证说明。

QA测试人员管理JIRA工作流程

标签!

如果您要添加有关机票的重要详细信息的评论,那么在评论中为QA测试仪标记很重要。即使票还没有准备好QA,这也是正确的。它将帮助他们准备正确测试它,或者使他们能够通过该方法提出潜在的问题。质量保证甚至可能已经开始编写测试用例,因此可以尽早访问其他信息可以改变游戏规则。

决定订单,然后坚持下去。

一些团队更喜欢设置JIRA评论以按顺序显示。其他人则是#TeamDescending(一个标签可能不会在Twitter上很快在Twitter上流行)。无论您做出哪种选择,请确保整个团队都知道。这听起来可能很小,但可能会产生真正的影响。很容易看到评论列表,并假定最近的评论位于顶部(或Vice-verse)。以错误的假设作用可以根据过期信息导致质量检查测试。

确定QA是否可以重新打开功能票,并用评论详细说明错误。

替代方案是100%的时间在单独的票证上放错误。能够添加带有错误详细信息的评论可以节省时间。但是虫子会以这种方式迷失。此外,如果开发人员的修复尝试未成功 - 或者如果有多个错误,则来回评论的列表很快就会变得笨拙。

Jira子任务

子任务是每个人都有自己方法的另一个领域。当错误与功能票有关时,一些团队有使用子任务的规则。例如,如果QA测试了一个配置文件部分并发现名称字段被打破,则他们可能会在配置文件功能票下创建此错误票作为子任务。从理论上讲,这是完全有道理的。但是实际上,由于以下原因,它可能导致敏捷的JIRA流程较少:

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

另一方面,如果错误与功能有关,则需要确保跟踪关联很容易。简单的解决方案是创建单独的错误票,但将其标记为“链接”,“由”或与功能票有关的任何形式的JIRA关系。这样一来,您仍然可以看到功能票的相关错误列表 - 而不会对整个董事会的视图/可用性产生负面影响。

分配JIRA门票

分配门票本身很容易。但是每个人都不时滑倒。以下是一些有潜在解决方案的受让人问题:

  • 开发人员不确定谁在有多个QA测试人员时分配机票。这可以通过多种方式解决。首先是在这种情况下有一个受让人。这可能是质量保证的领导者,他将决定如何分裂工作,也可能是项目经理。(如果有QA经理,这是另一个不错的选择。)另一种选择是将票证分配给一个人,但在票务评论中标记另一个。
  • 质量保证测试人员不确定哪些开发人员可以将错误门票分配给。通常,这是项目早期阶段的问题,或者是同一组件内有多个开发人员(例如,三个Android开发人员)。如果问题是QA(或开发人员)是该项目的新手,那么解决方案是提供团队成员及其角色的中心列表。如果问题是在同一区域中有多个开发人员,则可以以与上面的问题相同的方式解决这一问题 - 拥有将进一步审查机票的首选受让人。这可能是项目经理,也可以是首席开发人员。
  • 团队成员在不更新受让人的情况下更改机票状态(即:从“正在进行”到“准备测试”)。相关人可能会注意到看板董事会最终更新。但是,如果收到受让人的电子邮件通知,他们将能够更快地开始工作。每个人都会犯错误,但是这里的解决方案是始终提醒任何滑倒的人。

敏捷测试人员(QA测试人员在敏捷的JIRA Sprint板工作流程上举行门票)

另一个最佳做法是将质量检查添加到“观察者”列表中以获取任何相关门票。这样,即使有人忘记更新标签或受让人,他们也会看到更新。

优化QA的JIRA

Jira can feel unnecessarily complicated when you first get started, no matter what role you’re in. But if you optimize your Jira testing workflow and follow these best practices, you’ll be setting the stage for a more efficient process, happier teams, and a better end product.

将您的JIRA QA流程提升到一个新的水平

需要咨询您的质量检查过程吗?查看我们的按需质量检查测试服务。我们还进行敏捷咨询,并可以帮助优化您的JIRA QA流程。