Jira Hero 系列访谈：重新设计了 Jira Software 中的 Bug workflow

在 Atlassian，我们为自己发布的软件以及我们的客户在使用我们的产品以后取得的成功感到非常自豪。#Jiraheroes 是 Atlassian 社区的月度访谈系列。我们会邀请客户分享他们的成功故事。希望客户能够通过聆听我们的 #JiraHeroes 访谈系列如何克服他们的挑战，从中找到自己的成功之路灵感。

这一次，我们邀请了 @Soumen Deb，来自 Cognizant Technology Solutions 的质量工程和保证专家，帮助客户重新设计 jira software 中的 bug 工作流，提高可见性并简化开发过程。

问：请自我介绍并告诉我们，您的工作地点、角色和团队

我的名字是 Soumen Deb，是一家领先的跨国保险和金融服务提供商的质量工程和保证专家。我和我的团队都在新加坡。我的团队通过亚太地区项目的质量工程 quality engineering (QE） 和质量保证（quality assurance ）QA 实践为客户提供支持。

问：您的客户面临哪些挑战？这将如何影响您设计的集成 bug 工作流？

我与一家保险和金融服务提供商合作，拥有多个敏捷团队，每一个在 jira 软件 都有自己独特的 bug 工作流。这会导致各种问题，例如：

很难监视、评估和维护实例的运行状况。由于不同测试阶段的错误具有不同的工作流、转换和状态，因此几乎不可能全面了解程序的整体运行状况。唯一的解决方案是单独联系每个敏捷团队，但这将导致整个系统的视图脱节和孤立

创建报告和整合信息非常耗时。由于每个团队都有自己的 bug 工作流，因此必须在 jira software 外部手动导出和合并报告。这为人为错误留下了很大的空间

管理请求变得更具挑战性。无论哪个团队提出 bug 请求，都需要通过从低级环境到高级环境的质量检查点（质量保证-> 系统集成测试（SIT）-> 用户验收测试（UAT）→ 预生产）。随着程序越来越大，在开发过程中单独跟踪、修复和部署错误变得越来越困难。

我们需要的是一个集成的 bug 工作流：1） 遵守行业最佳 QA 实践，2） 清楚而独特地查看每个测试阶段的错误状态（InSprintQA、SIT 和 UAT）。也就是说，每个 bug 都需要遍历相同的流程，以便所有利益相关者的状态和转换保持一致

由于 jira 软件已经存在于我们的生态系统中，我们知道采用定制工作流将是一个简单而强大的解决方案。然而，在这个过程中，我需要记住以下几点：

这个新的 bug 工作流将只在新项目中实现。使用正在进行的项目实施新工作流可能会对现有数据集产生严重的负面影响

这个新的 Bug 工作流将可复用，并可轻松适应所有测试阶段（InSprintQA、SIT、UAT）。

这个新的 Bug 工作流将使应用团队能够选择 bug 生命周期的关键路径。也就是说，如果在 UAT 中发生错误，您需要修复错误并将其部署到 QA 环境，然后部署到 SIT 环境，然后部署到 UAT 环境。在所有环境中保持构建完整性。这是一种常见的不错做法。另一方面，当 InSprint 和 SIT  环境失效时，他们可以灵活地直接将 bug 修复部署到 UAT。

问：您是如何在 jira 中设计集成 bug 工作流的，以满足您的客户组织的独特需要

下游工作的统一愿景

在创建新的 bug 工作流之前，我与敏捷团队的领导进行了沟通，以了解更多信息并理解现有工作流背后的基本原理。每个团队都有相同的目标，即修复和部署 bug 以便在下一阶段重新测试，但除了他们自己的 scrum 团队之外，没有其他愿景。团队需要了解他们的工作如何顺流而下，以便整个组织能够顺利运行。在设计新的 bug 工作流程时，我始终牢记这一点。

我们工作流的敏捷迭代

初步分析后，我在 jira 软件 的沙盒版本中起草了一个新工作流。在这里，我根据从每个敏捷团队 Scrum Master 收到的反馈，定期对工作流进行更改。我每周定期与所有 Scrum Master 举行会议，以便我们能够建立共同愿景并提高重新设计过程的透明度。

试点实施

一旦我们确定了新的工作流程，我创建了一个虚拟项目并将其与错误问题类型相关联。 然后，我将工作流程交给了 QA 团队，他们在接下来的 2 天内进行了多次测试，以检查所有必要的用例。 一旦获得 “OK” 认证，我们的工具管理团队将工作流程推广到处于“试点阶段”的多个项目，工作流程的各个方面都得到了高度利用。 根据试点阶段的反馈对工作流程进行一些更改后，新的工作流程已准备好在所有团队中推广到新的敏捷项目。

新的错误工作流程的实施取得了巨大的成功。 简化的错误工作流程使我们的客户能够使用 Jira Dashboards 创建更好的报告。 客户的管理和执行团队能够通过在单个视图下查看每个测试阶段中的错误数量（按严重性、优先级）来评估程序的健康状况。 客户还可以为容易出现缺陷的组件及其 RCA 的每个测试阶段生成热图。

问：您分享了哪些最佳实践来帮助其他人思考如何创建自己的错误工作流程？

1. 所有敏捷团队都应该轻松适应 BUG 工作流程。 所有团队（例如开发、业务分析师、质量保证、项目管理、高管）都需要了解状态转换和状态。

2. 工作流程应涵盖所有关键的 QA 路径。 工作流程应确保 BUG 通过所有质量级别，然后才能被推送到下一阶段。

3. 引入强制输入字段，使工作流与 QA 流程紧密集成。 这样做是为了使用缺陷转储进行分析和回溯。

问：您能给新的 Jira 管理员提个建议吗？

始终在沙盒构建中尝试新的工作流程。 在推出试点使用之前，对所有用例进行适当的测试（这应该由独立的测试人员完成，而不是由参与创建工作流的人员完成）。 随时准备好回滚计划以备不时之需。