#JiraHero：Soumen Deb——重塑 Jira Software 中的 Bug 工作流，提高可见性、简化开发流程

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

本次我们邀请了 @Soumen Deb，Cognizant Technology Solutions 的质量工程和保证专家，他帮助客户重新设计了 Jira Software 中的 Bug 工作流，以改善报告功能、提高可见性并简化开发流程。

请先做个自我介绍，告诉我们您在哪里工作、您的角色以及您所在的团队。

我叫 Soumen Deb，是领先的跨国保险和金融服务提供商 Cognizant Technology Solutions 的质量工程和保证专家。我和我的团队常驻新加坡，我的团队通过亚太地区区域项目的质量工程 (QE) 和质量保证 (QA) 实践为客户提供支持。

您的客户面临着什么样的挑战，这对您设计一个集成的 Bug 工作流有什么影响?

我曾与一家拥有多个敏捷团队的保险和金融服务提供商合作，每个团队在 Jira Software 中都有自己独特的 Bug 工作流。这导致了各种不同的问题，例如： 

监控、评估和维护实例的运行状况很困难。

由于来自不同测试阶段的错误具有不同的工作流程、转换和状态，因此几乎不可能对程序的整体健康状况进行综合了解。唯一的解决方法是单独与每个敏捷团队联系，但这会造成整个系统的脱节和孤立的视图。

创建报告和整合信息非常耗时。

由于每个团队都有自己的 Bug 工作流，因此必须在 Jira Software 之外手动导出和合并报告。这为人为错误留下了很大的余地。

管理请求量变得更具挑战性。

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

我们需要的是一个集成的 Bug 工作流：1) 符合行业最佳 QA 实践，2) 对每个测试阶段（InSprintQA、SIT 和 UAT）的错误状态有清晰、独特的视图。也就是说，每个 Bug 都需要遍历相同的流程，以便状态和转换在所有利益相关者之间保持一致。

由于我们的生态系统中已经有 Jira Software，因此我们知道采用定制的工作流程将是一种简单而强大的解决方案。但是，在此过程中，我需要牢记以下几点： 

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

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

• 这个新的 Bug 工作流将使程序团队能够选择 Bug 生命周期的关键路径。也就是说，如果在 UAT 中出现错误，则需要修复该错误并将其部署到 QA 环境，然后是 SIT 环境，然后再部署到 UAT 环境。在所有环境中保持构建的完整性。这是通常遵循的最佳实践。另一方面，在 InSprint 和 SIT 环境退役的情况下，他们将具有直接将 Bug 修复部署到 UAT 的灵活性。

您是如何设计 Jira 中的集成 Bug 工作流来满足客户组织的独特需求的？

下游工作的统一愿景

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

我们工作流程的敏捷迭代

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

试点实施

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

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

您分享了哪些最佳实践，以帮助其他人思考如何创建自己的 Bug 工作流?

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

2. 工作流应涵盖所有关键的 QA 路径。工作流程应确保 Bug 通过所有质量关卡，然后可以推入下一阶段。

3. 引入强制输入字段，以便工作流与 QA 流程紧密结合。这样做是为了将缺陷转储用于分析和追溯。 

您能给一个新的 Jira 管理员一个建议吗?

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