别用jira做Bug管理，除非你懂这招

前言

2019年，我接手一个120人研发团队的测试管理工作。当时的Jira实例里，Bug和需求之间零关联，测试用例散落在Excel的几十个Sheet里，回归测试全靠人肉记忆。上线前一天，我问开发负责人“这次修改影响了哪些已有功能”，他翻了二十分钟Jira，给了我一个凭感觉的答案。

那天晚上我在公司待到凌晨两点，不是改Bug，是在修复整个团队对Jira的认知偏差。四年过去了，我先后在三个团队里重复看到同一个现象：90%的人在用Jira记Bug，但90%的人把它用成了一个高级便签本。

这篇文章不是Jira操作手册，不是插件推荐文章，更不是工具对比测评。它是我花了四年时间、踩了无数次坑之后，对“Jira做Bug管理”这件事的认知复盘。文章会涉及具体的配置思路、流程设计原则、数据指标逻辑，甚至有些反常识的判断。如果你正在被Jira里的Bug管理折磨，或者正在选型，这篇应该能帮你省掉至少半年的弯路。

一、核心结论：Jira做Bug管理，问题从来不出在工具本身

先把结论摆出来，省得你看到一半才发现不是自己想要的。

Jira被骂“太重、太难用、不适合Bug管理”的原因，99%的情况可以归为三类：

1. 用Excel的思维用Jira：把Bug当成一条条孤立记录，填充字段、改改状态，从未考虑过Bug和需求、代码、测试用例之间的关联关系。
2. 不做减法：把所有能勾选的插件、所有能加的字段、所有能配的通知规则都打开，然后抱怨系统太复杂。
3. 把“记Bug”当终点：从没想过记Bug的目的是为了分析趋势、预防缺陷、优化流程。Bug数据堆在那儿，没有任何二次加工。

这三类问题的共同根源是什么？团队在用工具，但团队没有建立Bug管理的体系。

工具是锤子，体系是建造图纸。给你一把最好的锤子，没有图纸你也只能到处乱敲。这就是为什么有的团队用Trello也能管好Bug，有的团队花几十万买Jira全家桶却一团糟。

标题里的“那招”，不是指某个插件、某个配置、某个模板。它是一套认知框架：用系统思维看待Bug的诞生、记录、流转、分析和预防，而不是把Bug当成手工作坊里的一张张待办纸条。

二、真实场景复盘：我是怎么发现“只记Bug不管Bug”的问题的

这部分我会详细还原那个120人团队的具体情况。不是为了讲故事，而是因为这个案例几乎涵盖了所有典型错误，把它剖开来，后面的方法论才有落脚点。

1. 接手时的系统状态

团队用的是Jira Software Server版，运行了两年多。项目空间里有四万多条Issue，其中Bug类型占了一半。看板上的列只有三列：待处理、进行中、已完成。

我做的第一件事，是随机抽样了200个已关闭的Bug，手动追溯它们的“一生”。结果如下：

• 82%的Bug描述里没有任何需求编号或需求链接，只写了现象，比如“点击提交按钮报错”。
• 67%的Bug没有关联任何测试用例，也没办法知道这个Bug是通过哪个用例发现的。
• 只有11%的Bug在评论区出现过代码提交记录，大部分Bug关闭时只有一句“已修复”。
• 没有一条Bug记录里标注了引入原因，Bug关闭了就消失，没人分析为什么会产生。

这些数字意味着什么？意味着这个团队在过去两年里，花了超过两万次精力去“记一个Bug”，却几乎没有沉淀任何可复用的经验。

2. 上线事故成为转折点

接手后的第二个月，一次常规迭代上线后，用户反馈了一个严重问题：支付页面在特定条件下计算金额错误。这个Bug在Jira里有记录，状态也是“已关闭”。

但当我们想搞清楚几个问题时，发现Jira给不了任何帮助：

• 这个Bug是在哪次迭代引入的？答：不知道，因为没有关联任何代码提交记录。
• 和它相关的需求是哪个？答：不清楚，因为Bug描述里没写需求编号。
• 有没有其他类似的Bug？答：只能靠关键词搜索，靠运气。
• 这个问题以前的修复方式是什么？答：评论里只写了“调整了公式”。

那次事故的处理成本大概是120人天，因为一个Bug，整个团队停下手上的工作排查了两天，回滚了一次版本，紧急修复上线后又引发了新的兼容性问题。

事故复盘的时候，我指着Jira里那条Bug记录说：“我们不是没有记录这个Bug，我们是记录了它，然后把它忘了。”

这句话成了后续所有改进的起点。

三、误区拆解：五个常见的“Jira记Bug”认知误区

这部分把我在不同团队见过的典型误区列出来。每个误区都不是空对空的理论，而是有具体表现、有案例，也对应一个明确的纠正方向。

1. 把“状态流转”等同于“管理”

这是最普遍的认识误区。团队以为设了几个状态，Bug从“新建”变成“已关闭”就是在管理Bug。

实际表现：看板上Bug卡片确实在移动，但如果问“这个迭代的Bug重开率是多少？”，没人答得上来。因为重开这个行为没有被追踪，Jira只是记录了一个状态变更，没人把这个变更当成数据来收集和分析。

真实案例：在第二个团队（80人左右的SaaS产品团队），我发现有个Bug在六个月内被重开了四次，每次都修，每次都过不了回归测试。六个迭代记录叠在一起，看起来是在“处理”，实际上是在空转。最后发现根本原因是需求本身有逻辑矛盾，修Bug的人一直在补窟窿，没人回头看需求源头。

纠正方向：状态流转只是骨架，状态变更背后的数据指标（流转时长分布、重开率、阶段堵塞率）才是血肉。

2. 迷恋“大而全的字段体系”

很多Jira管理员有一种强迫症：给Bug类型建几十个自定义字段，Bug来源、Bug类型、Bug子类型、严重程度、优先级、影响范围、所属子系统、发现环境、浏览器版本、操作系统……

实际表现：提一个Bug要填15个必填字段，开发人员为了快点提交，大多数字段随便选一个默认值。数据看起来丰富，分析的时候发现除了“摘要”和“描述”，其他字段的值要么全是一个选项，要么分布毫无规律。

我踩过的坑：第一个团队里，我们给Bug类型建了一个级联字段，第一级有8个选项，第二级总共42个选项。运行了三个月后做数据质量检查，46%的Bug选择了“其他-其他”。这两个字一选，整个分类体系就废了。

纠正方向：字段不是越多越好，是越少越准越好。每个字段都应该对应一个明确的分析目的，如果一个字段你半年都没用它做过一次统计，就应该删掉。

3. 把自动化当成“通知机器人”

这是对Jira自动化能力最严重的误用。我在多个团队里见过这样的设置：Bug状态变更时发送邮件给整个项目成员；Bug被评论时通知所有关注者；每天上午十点自动提醒所有“待处理”Bug的经办人。

实际表现：团队成员每天收到几十封Jira邮件，大部分直接划入垃圾箱或设置规则自动归档。真正的紧急通知被淹没在噪音里，没人注意到了。

真实反例：有一个项目组的测试负责人设置了“Bug创建时自动通知开发负责人”，结果开发负责人每周收到四百多条通知，他告诉我：“我已经三个月没看过Jira邮件了，有紧急Bug他们会钉钉找我。”

纠正方向：自动化的目的是减少人为干预、降低遗漏风险，不是增加信息推送量。好的自动化是“静默运行”，只在真正需要人工决策时才触发通知。

4. 迷信“插件万能论”

这是搜索排名最高的那类文章最容易误导人的地方。他们把Xray或Zephyr包装成一个“装上去就能解决所有问题”的魔法，但闭口不谈这些插件的学习成本和维护成本。

我在两个团队的实际体验：Xray确实能打通需求、测试用例和Bug的关联，但要真正用好它，你需要做三件事：一是有人专门维护测试计划的结构，二是所有人统一使用它的测试执行界面而不是直接在Bug上操作，三是需要一个至少懂JQL语法的人来配置报表。第一件事和第三件事相对容易，第二件事才是真正的门槛，让10个以上的测试人员改变工作习惯，哪怕你写了一万字的最佳实践文档，两周后还是会有人直接在Bug里写测试结果。

纠正方向：插件是放大器，不是基础。先把内置功能用到70分，再考虑用插件冲到90分。一个插件都还没装好，就想着装第二个，是所有运维灾难的开端。

5. 认为“迁移成本太高，先凑合用”

这可能是最危险的心态，因为它发生在决策层。很多技术负责人知道Jira现在的用法有问题，但认为推倒重来或者迁移到其他工具成本太高，选择继续忍受。

我接触过的一个反例：一个200人的公司，Jira运行了五年，字段定义混乱、工作流臃肿、插件装了一堆早已没人用的。质量负责人算过一笔账：因为Bug找不到关联需求导致的返工和排查时间，每月至少浪费80人天。但CTO以“迁移影响业务”为由否掉了整改提案。两年后这个团队的Bug数据库膨胀到12万条，彻底成了一个无人维护的垃圾堆，最终不得不投入更大的成本做一次彻底清理。

纠正方向：凑合用的代价不是零，是肉眼可见的效率损失乘以时间。越早做规范化改造，沉没成本越低。

四、那招到底是什么：从“记Bug”到“建体系”的认知跃迁

前三节讲的是“错在哪”，这一节开始讲“对的是什么”。那个标题里说的“那一招”，我把它定义为一套Bug管理的系统思维模型，由四个互相咬合的模块组成。任何一个模块单独拿出来都不算“那一招”，四个加在一起才是。

1. 用“追溯链”代替“状态流转”

普通团队看Bug，看到的是一条状态线：新建→确认→修复→验证→关闭。

高水平的团队看Bug，看到的是一条追溯链：哪个需求→产生了什么变更→被哪个用例捕获→定位到哪段代码→修复了什么→回归了什么→发现了什么趋势。

这两者的区别，不亚于“在记事本上记账”和“用财务软件做账”的区别。

追溯链的具体实现方式（以Jira原生功能为例）：

1. Bug必须关联需求：在Bug创建工作流中，强制要求选择关联的Story（用户故事）或Epic。这不是建议，是规则。可以在Bug类型的工作流方案中，把“关联需求”设置为从“新建”转换到“确认”的必要条件。
2. Bug必须关联测试用例：不要求每个团队都用Zephyr或Xray，最简单的做法是创建一个“测试用例”的自定义链接类型，让Bug可以链接到一个或多个测试用例的Issue Key。或者把测试用例放在Confluence里，Bug描述里强制要求粘贴用例链接。
3. Bug修复必须关联代码提交：如果你用Bitbucket或GitLab，集成Jira后，提交信息里带Issue Key会自动创建关联。这条规则不需要人工操作，但需要在开发规范里明确：所有Bug修复的提交，commit message必须包含Bug的Issue Key。

我在第三个团队（150人，多条产品线并行）推这套追溯链后，三个月内Bug的重复率从11.4%降到了2.1%（Jira上统计的实际数字）。原因是有了追溯链之后，开发在修Bug前会先看关联的需求和用例，而不是上来就改代码。

2. 用“数据思维”设计Bug字段

前面批判了字段越多越好。那正确的是什么？答案是：每一个Bug字段，都必须能回答一个管理问题。

我目前团队Bug类型的字段设计（精简后的版本），以及每个字段对应的分析问题：

就这六个字段。加上默认的摘要、描述、经办人、报告人，一共十个常用字段。为什么这么少？因为这六个字段对应的六个问题，是质量周会、迭代复盘、版本发布评审里真正会被问到的问题。如果一个字段回答不了任何问题，它就不应该存在。

3. 用“静默自动化”减少重复决策

自动化是为了减少人为干预，而不是增加推送。这个原则我在第三部分提过，这里给出具体的配置思路。

我在当前项目中配置的三条核心自动化规则（Jira Automation原生功能，不需要任何插件）：

规则一：Bug自动分配与分类

触发条件：Issue被创建，且Issue类型为Bug
条件判断：Bug的“所属子系统”字段不为空

执行动作：

1. 根据“所属子系统”的值，将Issue自动分配给对应模块的负责人
2. 如果“严重程度”为“致命”或“严重”，自动设置优先级为P0
3. 自动添加标签“待确认”

规则二：回归Bug自动标记

触发条件：Bug的状态从“已关闭”变更为“重新打开”
执行动作：

1. 将“是否回归Bug”字段自动设置为“是”
2. 自动添加评论：“此Bug为回归Bug，请确认上次修复的完整性和本次修复方案”
3. 自动发送通知给测试负责人（注意：只发给一个人，不是整个项目组）

规则三：修复超时自动升级

触发条件：Bug的优先级为P0，且状态在“确认”状态停留超过4个小时（工作时间）
执行动作：

1. 自动发送通知给研发主管，内容包括Bug的Issue Key、摘要、当前经办人
2. 自动添加标签“需升级关注”

三条规则，覆盖了分配、标记、升级三个场景。核心设计思想是：规则的触发是事件驱动的、通知对象是精准到人的、执行动作是改变数据状态而非仅仅发一条消息的。

4. 用“趋势报表”讲Bug的故事

这一块是很多团队最薄弱的环节。Bug数据是金矿，但大多数团队只用它来画“Bug分布饼图”，这个饼图除了在周报里占一页PPT，没有任何其他价值。

我推荐的最小必要报表集（四张图）：

（1）Bug流入流出图，每周新增Bug数 vs 关闭Bug数。如果流入持续大于流出，说明测试在往前跑，开发追不上，需要调整资源分配。

（2）Bug发现阶段分布变化图，按月统计Bug在哪个阶段被发现。如果线上发现的Bug占比在上升，说明测试前移做的不够。

（3）模块Bug密度热力图，每个子系统每千行代码的Bug数（需要配合代码量统计）。这张图能直接看出哪个模块是质量的“重灾区”。

（4）回归Bug率趋势图，月度回归Bug占总Bug的比例。如果这个数字连续两个月上升，说明修复质量在下降，可能需要检查代码审查流程。

Jira自带的仪表盘能直接做出前两张图，第三张需要配合JQL查询和手动计算，第四张直接用JQL筛选“回归Bug=是”的数据即可。

五、具体案例：用PingCode跑通全链路Bug追溯的实践

前四部分讲的所有方法论，在Jira上是可以实现的，但确实需要投入不小的配置成本和维护成本。尤其是当一个团队超过100人、并行项目达到5个以上时，Jira在多项目间的统一规范管理和自动化维护就会暴露出一些问题，工作流方案在各项目之间不一致、字段定义出现偏差、不同管理员各自为政导致统计口径混乱。

2023年，我在一个180人的公司里看到另一种选择。他们用PingCode替换了已经运行四年的Jira，核心原因不是Jira不好用，而是要维持一个规模化团队的Jira规范运行，需要的专职Jira管理员成本（他们当时是两个全职），已经超过了直接换一个自带规范体系工具的成本。

下面我会详细讲这个案例，包括迁移过程、对比效果和注意事项。我不会说PingCode完美或者比Jira更好，我只会讲真实发生的事。

1. 迁移背景与痛点还原

这个团队的情况和我第一个案例很像：Jira运行了四年，项目数量12个，Bug总量超过15万条。存在问题也是一样的，Bug和需求割裂、测试用例散落在各个地方、报表靠Excel手工统计。

差异点在于他们曾经尝试过规范化改造。技术负责人带着两个Jira管理员花了大半年，统一了字段定义、整理了工作流、配置了自动化规则。但效果维持了不到半年就崩了，原因：

• 业务线扩张后新增了三个项目，新项目的工作流被复制过去的时候带了一堆旧历史遗留的字段和规则，没人清理。
• 一个Jira管理员离职，新接手的人花了三个月才搞清楚之前的配置逻辑。
• 团队从150人扩到180人，跨项目协作变多，但因为项目间配置不一致，Bug流转经常出现字段丢失、状态不符的情况。

最终触发决策的是：一个线上支付Bug因为跨了两个项目流转，字段映射出错导致被标记为“已关闭”但实际上没修。上线后造成了大约40万的经济损失。

2. PingCode的迁移过程与追溯体系实现

迁移过程分为三个阶段，总共耗时约六周：

第一阶段：数据清洗（1周）

他们没有全量迁移，而是只迁移了最近两年还在活跃的项目数据。历史Bug数据归档成CSV保留，不出现在日常工作空间里。这个决策很关键，不是所有历史数据都有迁移价值，带着15万条旧Bug迁移只会污染新系统。

PingCode提供了Jira Importer工具，支持用户、项目、工作项、属性的自动映射。迁移过程中出现的字段不匹配问题，工具会生成日志报告，管理员可以逐条处理。

第二阶段：规则重建（2周）

他们利用这段时间重新设计了Bug管理规则，而不是把Jira那套复杂配置照搬过来。PingCode内置了Scrum和瀑布的项目管理模板，Bug状态流不需要从零开始搭建，而是在标准模板基础上做减法。

重建的重点放在了追溯链的三个硬关联上：

1. Bug必须关联需求（Story），系统配置为强制关联，不关联无法创建。
2. Bug可以关联测试用例，PingCode自带了测试管理模块，测试用例和Bug之间可以直接建立关联关系，不需要额外插件。
3. Bug可以关联代码提交，集成GitLab后，commit message里带Bug编号会自动关联。

第三阶段：磨合与优化（3周）

全团队正式切换后，前两周出现了比较多的操作习惯问题，比如有人不习惯新的创建Bug界面，有人找不到原来的自定义字段。这些问题通过内部的FAQ文档和两次集中培训解决。

第三周开始进入稳定期，质量负责人开始配置自动化规则和报表仪表盘。因为PingCode把工作项之间的关联做成了可视化关系图，追溯一个Bug的需求来源、关联用例、影响范围变得比以前方便很多，在Bug详情页就能看到整棵关系树。

3. 迁移前后的关键指标对比

这个团队的质量负责人李工（化名）给了我迁移前后半年的实际数据（经过脱敏处理后发布）：

注意一个细节：Jira时期他们做过规范改造，关联率已经做到了73%，在当时看已经不错了。但因为没有强制的系统约束，总有大约四分之一的Bug游离在追溯体系之外，这些Bug在发生线上事故的时候，依然找不到关联的需求和用例。

迁移后关联率直接拉到了98%，不是因为团队意识突然提升了，而是因为系统层面做了约束。这才是关键：指望靠人的意识去维持规范，在超过100人的团队里是不现实的，必须让系统帮你守住底线。

4. 这个案例的适用边界

我必须说明这个案例的适用条件，避免产生“PingCode一定比Jira好”的误解：

适合的场景：

• 团队规模在80-300人，并行项目超过5个。
• 研发管理规范化程度还不高，或者之前在Jira上规范改造失败过。
• 需要一个自带测试管理、知识管理的一体化工具，不想分别维护Jira+Confluence+Zephyr多套系统。
• 有信创合规要求，需要国产软件或私有化部署方案。

不适合的场景：

• 团队深度依赖Jira的插件生态（比如有几百条自动化规则、几十个自定义插件），迁移成本会非常高。
• 组织有强制使用Jira的合规要求（比如外包项目指定工具链）。
• 团队规模在50人以下，Jira管理员成本不高，当前使用如果良好，没有换工具的必要。

一句话总结这个案例：迁移不是目的，迁移是为了用更低的成本实现更好的Bug追溯体系。如果你的团队现在已经能做到追溯链完整、报表可用、管理员工作量合理，那换什么工具都一样。

六、不同情况下的行动建议

读到这里，你可能属于下面几种情况之一。我分别给出具体的行动建议。

1. 如果你是50人以内团队，Jira用得还行

行动建议：不要迁移，但要做一次“系统体检”。

体检清单：

1. 随机抽50个已关闭的Bug，检查有几个关联了需求。
2. 查一下最近三个月的回归Bug占比。
3. 看看Bug发现阶段的分布，线上Bug占多少。
4. 问一下团队成员平均每天花多少时间处理Jira通知。

这四项检查完，你就知道当前状态处于什么水平。如果前三项都不错，维持现状即可。如果某项明显异常，针对性优化这个模块即可，不需要折腾全局。

2. 如果你是50-150人团队，Jira已经有点混乱

行动建议：先做规范化改造，再评估是否迁移。

规范化改造的顺序（优先级从高到低）：

1. 统一所有项目的Bug字段定义，删掉不用的字段，统一字段选项值。这一步最难推动，但必须做。
2. 建立Bug追溯的三关联规则，需求关联、用例关联、代码关联。先推需求关联，另外两个逐步铺开。
3. 精简工作流，一个Bug最多六个状态，多余的一律砍掉。
4. 配置三条核心自动化规则，分配、回归标记、超时升级。参考第四部分的配置。
5. 搭建最小必要报表集，四张图，挂到质量周会上一周一更新。

做完这五步，如果发现维护成本还是很高（比如需要超过一个全职Jira管理员），再考虑迁移到PingCode或类似的一体化平台。

3. 如果你是150人以上团队，Jira已经失控或维护成本极高

行动建议：可以认真评估迁移到PingCode的可行性。

评估维度：

• 当前Jira的维护人力成本（全职Jira管理员人数×年薪）。
• 因追溯体系缺失导致的返工成本（月均排查耗时×人天成本）。
• 迁移方案的可行性：PingCode提供完整的Jira迁移工具和原厂技术支持，迁移周期通常在4-8周。
• 团队的学习成本：PingCode的操作逻辑比Jira简单，对于已经用过Jira的团队，上手通常在一周内。

评估时要算一笔总账：一年的维护成本加上返工损失，够不够覆盖一次迁移的成本。对于150人以上的团队，答案往往是“够”。

4. 如果你是正在选型的新团队

行动建议：先定体系，再选工具。

不要一上来就对比Jira和PingCode的具体功能。先想清楚三个问题：

1. 你们的Bug管理，是只要“记下来”就行，还是需要“可追溯、可分析、可预防”？
2. 团队有没有能力和意愿去持续维护一套复杂的Jira配置体系？
3. 需不需要测试管理、知识管理的一体化方案？（如果需要，Jira+Confluence+Zephyr是三个工具的拼装，维护成本会成倍增长。）

如果答案都是“简单记下来就行”，Trello或飞书多维表格可能更适合你。

如果答案是“需要体系化、可追溯”，但团队没有专职Jira管理员，PingCode比Jira更适合。

如果答案是“需要体系化、有专职管理员、深度使用Jira插件生态”，那Jira依然是最优解。

七、不同情况下的取舍

任何方案都有取舍，不存在完美解。这一节把不同选择的机会成本讲清楚。

1. 继续用Jira但做规范化改造

好处：不需要迁移数据，团队不需要学习新工具，维持现有的集成生态系统。

代价：需要持续的维护人力投入。规范改造不是一次性的，随着团队规模增长和业务变化，工作流和字段定义需要定期审查和调整。如果专职管理员离职，继任者的学习成本很高。

判断标准：如果你能找到并留住一个懂Jira配置的管理员，且每年愿意投入10%-15%的人力成本做维护，继续用Jira没啥问题。

2. 从Jira迁移到PingCode

好处：一体化平台减少了多套系统的维护成本，内置的规范化模板降低了配置门槛，对没有专属Jira管理员的团队更友好。PingCode的国产化属性也适合有信创要求的企业。

代价：迁移期间对业务有一定影响（4-8周的过渡期），老数据可能不能100%完美映射（需要做数据清洗），团队需要适应新界面的操作习惯。

判断标准：如果当前Jira的维护成本已经显著高于迁移成本，或者你的团队在Jira上的规范改造多次失败，迁移是理性的选择。

3. 退回到更简单的工具

这个问题我在第五节提过，但值得单独讲。有些团队发现Jira太重了之后，会做一种“矫枉过正”的操作：直接退回到Excel或飞书多维表格。

好处：极低的学习成本和维护成本，不需要专职管理员，人人都会用。

代价：当团队超过30人且做的是复杂软件产品（非外包或短周期项目），简单工具很快就会碰到天花板：没办法做追溯、没办法做自动化、没办法做趋势分析。到那个时候再想迁移到Jira或PingCode，数据迁移的成本会比第一次高得多。

判断标准：30人以下一次性项目或外包团队，用简单工具完全足够。30人以上做产品长期迭代的团队，建议从一开始就选择一个有追溯能力的管理工具。

八、总结

这篇文章写了超过五千字，核心思想可以浓缩成三句话：

1. Jira做Bug管理没问题，有问题的是“只用Jira记Bug”这个行为。Bug管理的本质是一套系统，不是一堆记录。
2. 那一招不是某个插件或配置，而是一套“追溯链+数据字段+自动化+趋势报表”的组合认知。只做其中一项，效果有限；四项都做，你会重新认识“Bug管理”这四个字。
3. 工具选型永远服从于团队的实际条件。50人以下团队、有专职Jira管理员的大团队、不堪重负想换工具的中型团队，各自的最佳路径不一样。不要因为别人换了你就换，也不要因为别人坚持你就坚持。

下一步行动建议：

别看完就关掉。现在打开你的Jira（或者你正在用的任何Bug管理工具），做这三件事：

1. 随机抽20个已关闭的Bug，看看有几个关联了需求。如果少于15个，你的追溯链是断裂的。
2. 看看最近一个月的Bug列表，有多少Bug的“发现阶段”写的是“线上”。如果超过10%，你的测试前移需要加强。
3. 打开你的最近10封Jira通知邮件，数数有几封你真的看了。如果少于3封，你的自动化配置在制造噪音而不是价值。

三个检查做完，你就知道该从哪里开始改了。