StatusPath Reports使用指南
如何分析 Jira 中的 QA 或测试阶段瓶颈
分析 Jira QA 瓶颈时，应把测试前等待、Testing 状态停留和重新测试循环分开。先比较 Waiting for QA、Testing 和 Ready for Retest 的时长，再用 Status Count 与 Transition Count 找出重复进入 Testing 的工作项及其流转路径。状态停留只能作为流程经过时间的证据，不能等同于测试人员工时、缺陷原因或个人绩效；示例状态名还必须映射到本地工作流。
分别定义 QA 排队、测试阶段和重新测试循环
有效的 QA 瓶颈分析应拆成三个更具体的问题：
| 问题 | 示例工作流证据 | 报表 |
|---|---|---|
| 测试开始前，工作等待了多久？ | Waiting for QA 时长 | Time in Status |
| 工作在测试阶段状态中停留多久？ | Testing 时长 | Time in Status 或 Average Time in Status |
| 哪些 Bug 返回并进行了另一轮测试？ | Testing 进入次数和定向 reopen 流转 | Status Count 和 Transition Count |
本页只处理这三个 QA 阶段问题。如果疑似约束可能位于交付工作流中的任何位置，请使用Jira 工作流瓶颈指南；如果需要不限定 QA 的通用方法，请使用Jira 返工指南。
Atlassian 将 Jira 工作流定义为工作项在生命周期中经过的状态和流转。示例中的名称不是通用标准。开始计算前，应把每个本地工作流中的状态映射到以下分析角色：
| 分析角色 | 本示例使用的状态 | 可能的本地名称 |
|---|---|---|
| QA 队列 | Waiting for QA | QA Ready、Ready for Test、Awaiting Validation |
| 测试阶段 | Testing | In QA、Test in Progress、Validation |
| 重新测试队列 | Ready for Retest | Fix Ready、Awaiting Retest、Ready for QA |
| Reopen 信号 | Testing → Reopened | QA Failed、Reopen Bug、Return to Development |
诊断前不要把四种角色合并为一个“QA”数字。宽泛的状态分组可以在后续管理汇总中使用，但它会隐藏时长究竟来自排队、Testing 状态，还是返回路径。列和分组文档说明了 StatusPath 状态分组如何汇总所选状态的时长或进入次数；跨团队使用不同名称时，应同时公布映射规则。
可复现的 Jira 测试场景：18 个 Bug 经过 QA
报表范围包含 SR-3301 至 SR-3318，截图使用 Jira 测试项目中的合成演示数据。保存的示例使用名为 All time (UTC) 的 24×7 计算日历，将计算时区固定为 UTC；输出格式为 Decimal Hours，计算完整场景历史，并将 Waiting for QA、Testing、Ready for Retest 保持为三个独立列。这个命名日历属于可复现的示例配置，并非 Jira 或 StatusPath 的默认日历；替换为团队工作日历前，请先查看日历与时长格式文档。
前 15 个 Bug 经过正常路径：
In Progress → Waiting for QA → Testing → Done
- Waiting for QA 时长按
8h、10h、12h循环 5 次：5 × (8h + 10h + 12h) = 150h。 - Testing 时长从 4h 开始按
4h、6h交替：8 个 Bug 各贡献 4h，7 个 Bug 各贡献 6h，即8 × 4h + 7 × 6h = 74h。
其余 3 个 Bug，即 SR-3316 至 SR-3318，经过重新测试路径：
In Progress → Waiting for QA (8h) → Testing (4h) → Reopened (1h)
→ In Progress (3h) → Ready for Retest (2h) → Testing (3h) → Done
这 3 个 Bug 每个都向 Waiting for QA 贡献 8h，两次 Testing 合计贡献 7h，并向 Ready for Retest 贡献 2h。
使用以下可复现配置：
| 设置 | 值 |
|---|---|
| 工作项范围 | JQL：project = SR AND issuetype = Bug ORDER BY created ASC；确认结果包含 SR-3301 至 SR-3318 |
| 报表类型 | Time in Status |
| 历史范围 | 完整场景历史；不设置 Trim History 边界 |
| Calendar | All time (UTC) |
| Format | Decimal Hours |
| 时长列 | Waiting for QA、Testing、Ready for Retest |
| 核查字段 | Work item key、Summary、Current status |
计算排队、Testing 和重新测试时长
每个状态应独立计算，并使用实际进入该状态的 Bug 数作为分母：
| 状态 | 正常路径总计 | 重新测试路径总计 | 贡献 Bug 数 | 总计 | 每个贡献 Bug 的平均值 |
|---|---|---|---|---|---|
| Waiting for QA | 150h | 3 × 8h = 24h |
18 | 174h | 174h ÷ 18 = 9.67h |
| Testing | 74h | 3 × (4h + 3h) = 21h |
18 | 95h | 95h ÷ 18 = 5.28h |
| Ready for Retest | 0h | 3 × 2h = 6h |
3 | 6h | 6h ÷ 3 = 2.00h |
Testing 的分母是 18 个 Bug，不是 21 次进入。3 个重新测试 Bug 仍各占一行，其两段 Testing 区间合计为 7h。Ready for Retest 使用 3 个贡献 Bug，因为另外 15 个从未进入该状态。
在这一范围内，Waiting for QA 的总计和平均值最大，因此测试前队列是一个候选瓶颈。计算本身不能识别成因；形成假设前，还要检查优先级、环境可用性、发布时间以及底层工作项。
确认信号在可比周期中持续
一个包含 18 个 Bug 的总体只能指出候选项，不能证明它是持续约束。应选择另一周、另一月或规模相近的发布总体，并保持工作项范围、状态映射、Calendar、Format 和 Trim History 规则不变。每个状态都要同时报告汇总时长与贡献 Bug 数；大量 Bug 共同形成的高总计，与一个异常值造成的高总计含义不同。
如果 Waiting for QA 在可比周期中持续偏高或上升，而且贡献数量始终可见，瓶颈判断会更有依据。如果信号消失，应先检查总体构成和配置变化，再宣称流程已经改善。上游的代码评审瓶颈分析也应采用相同的持续性检查。
使用进入次数找出重新测试候选项
保持工作项范围和历史窗口不变，将报表切换为 Status Count。15 个正常路径 Bug 只进入 Testing 一次；SR-3316、SR-3317 和 SR-3318 各进入 Testing 两次，因此这 3 行是重新测试候选项。
正常路径 Testing 进入次数 = 15 × 1 = 15
重新测试路径进入次数 = 3 × 2 = 6
全部 Testing 进入次数 = 15 + 6 = 21
第二次进入 Testing 是重复流转证据，但不是原因解释。工作项可能因缺陷、需求变化、环境问题、自动化规则或其他有效工作流路径而 Reopened。分类前必须继续检查 Transition Count 和 Jira History。
确认 QA 循环的流转方向
Atlassian 说明工作流流转是单向的。从 Testing 移到 Reopened，与随后从 Ready for Retest 返回 Testing，是两条独立流转。应统计书面重新测试定义要求的具体方向，而不能把每次进入 Testing 都视为相同事件。
本场景的三组关键流转总计为：
| 流转 | 总次数 | 在本工作流中的含义 |
|---|---|---|
| Testing → Reopened | 3 | 3 个 Bug 通过 Reopen 路径离开测试阶段 |
| Reopened → In Progress | 3 | 同一组 3 个 Bug 返回开发阶段 |
| Ready for Retest → Testing | 3 | 3 个 Bug 开始另一轮测试 |
JQL 可以帮助筛选经历过某条已知流转的 Bug：
project = SR
AND status CHANGED FROM "Testing" TO "Reopened"
ORDER BY key ASC
Atlassian 的 JQL 运算符参考说明，CHANGED 支持 FROM、TO、AFTER、BEFORE 和 DURING 等条件。上面的查询可以找出匹配该路径的工作项，但标准 JQL 搜索不会生成“每个工作项发生过多少次”的次数列。需要次数时，应使用 Transition Count 或基于 changelog 的计算。
建立可重复执行的 QA 瓶颈检查
1. 写出本地状态映射
记录哪些状态分别代表等待、测试阶段、等待重新测试和返回开发。如果两个 Project 使用不同名称，应分开分析，或创建有明确文档的状态分组，同时保留底层状态证据。
2. 固定工作项范围和历史窗口
选择 Project、Saved Filter、JQL、Sprint 或 Epic，并记录 Work item date range 与 Trim History 规则。工作项选择时间和参与计算的历史时间回答不同问题。三种报表必须使用相同范围；控件说明见报表设置与范围，边界模型见Jira Time in Status 日期范围如何裁剪历史。
3. 从 Time in Status 开始
将排队、Testing 和重新测试列分开。分别排序时长列，检查分布，并把可见行与状态总计对账。解释 Average Time in Status 前，应使用同一范围的 Time in Status 或 Status Count 行核对贡献工作项数。
4. 使用 Status Count 筛选
查找 Testing 或 Ready for Retest 中高于正常路径预期次数的值。次数大于 1 只表示候选信号，仍需检查流转路线。
5. 使用 Transition Count 诊断
选择团队书面定义中的具体正向和反向流转。受影响 Bug 数与流转事件数应分别报告。
6. 在 Jira 中核查代表性 Bug
打开一个 Waiting for QA 时长较长的工作项、一个正常 Testing 工作项，以及每个高次数重新测试工作项。Atlassian 将 Activity → History描述为记录字段编辑和工作流移动的位置。判断原因前，应先还原时间戳和流转方向。
7. 比较一个可比周期
使用相同的范围定义、状态映射、Calendar、Format 和 Trim History 规则，对另一个周期重复运行报表。把每个状态总计和贡献 Bug 数放在一起，避免把总体规模变化误判为流程变化。
8. 记录可验证的后续假设
例如检查输入批次、环境就绪、优先级规则或 Reopen 标准。每次只改变一项策略或约束，再使用相同范围、状态映射、Calendar 和历史规则比较下一周期。
常见错误
过早合并排队和测试时间
单个 QA 状态分组可以显示宽泛总计，却无法说明工作是在等待开始、停留于 Testing，还是等待重新测试。诊断时应保留底层状态列。
把状态停留等同于测试人员工时
Testing 时长是所选 Calendar 下的经过时间或工作时间，可能包含无人处理、环境延迟、交接、自动化和非工作时段。它不是工时表。
根据 Reopen 流转直接指定缺陷原因
Testing → Reopened 只证明发生过工作流移动，不能证明移动原因。分类前要检查 Bug、评论、字段和 History。
使用错误分母
Ready for Retest 的平均值应使用实际进入该状态的 3 个 Bug，而不是全部 18 个。Testing 虽然有 21 次进入，平均值仍基于 18 个贡献 Bug。
期望 JQL 生成流转次数
status CHANGED FROM ... TO ... 适合筛选已知路径，但不能代替逐工作项的 Transition Count 结果。
常见问题
哪个 Jira 状态能证明存在 QA 瓶颈？
没有任何单个状态可以证明。应同时比较排队时长、Testing 时长、贡献工作项数、重复进入、定向流转和代表性 Jira History；结论还必须符合本地工作流定义。
Waiting for QA 和 Testing 应合并为一个状态组吗？
首次诊断时不应合并。保持分开才能区分排队和测试阶段停留。后续可以增加一个有明确文档的组合分组，用于更宽泛的汇总。
Testing 时长较长是否表示测试人员投入了同样多的工时？
不是。它表示工作项在所选 Calendar 和历史规则下占用该状态的时间，不能直接衡量测试人员实际操作时间。
JQL 能找到经过重新测试循环的 Bug 吗？
JQL CHANGED FROM ... TO ... 可以筛选经历过指定移动的 Bug，但不显示逐项发生次数；多个 change 条件本身也不能证明各事件之间的时间顺序。应使用 Transition Count 和 History 核查路径。
这 3 个重新测试 Bug 应如何报告？
应同时报告两个层次：18 个 Bug 中有 3 个两次进入 Testing；定义中的 Testing → Reopened、Reopened → In Progress 和 Ready for Retest → Testing 又各发生 3 次。事件证据应与后续原因分类分开。
相关指南
- 如何查找 Jira 工作流瓶颈
- 如何用 Status Count 和 Transition Count 分析 Jira 返工
- 如何计算 Jira Cloud 中的状态停留时间
- Jira 工作流报表完整指南
- 如何在 Jira 中发现代码评审瓶颈
- Jira Time in Status 日期范围如何裁剪历史
把 QA 延迟转化为可核查的工作流问题
提出改进方案前，应先把排队、Testing 和重新测试证据分开。StatusPath Reports 可以在同一个 Jira 范围内计算三类状态时长、筛选重复进入 Testing 的工作项，并显示具体流转方向。