使用 PDCA 模型进行测试流程改进 (TPI)
托马斯·汉密尔顿
什么是测试流程改进？
测试流程改进 测试优化是指衡量测试流程的绩效，识别其薄弱环节，并进行可控的改进，从而使下一个项目能够以更低的成本和更短的时间交付更高质量的成果。它将测试视为一个可以衡量和调整的过程，而不是每次发布都以相同方式重复的活动。
想象一下 Guru99银行项目刚刚完成。管理层对你的工作表示赞赏，客户也很满意。即便如此，你的老板还有一些问题要问你。
管理者经常描述 软件测试 作为一个棘手且难以控制的过程。回顾过去…… Guru99银行项目，您是否遇到过以下任何问题？
这些几乎是所有测试项目中都会遇到的常见问题。许多组织意识到，改进测试流程是解决这些问题的唯一持久途径，因为只有从过去的错误中吸取教训，才能防止同样的错误在下一个发布周期中重演。
为什么要改进测试流程？
以下场景说明了测试流程改进的重要性。 Guru99银行项目已完成，测试质量很好，并收到了客户的良好反馈。
从这个例子中我们能学到什么？答案很简单。 “永远努力做得更好”即使你认为自己做得很好，也总会有人做得更好，因为他们找到了比你更好的想法和解决方案。
每个企业都希望项目按时完成。 最高 质量方面 最低 成本，以及在 最短的 交付时间。测试流程改进能够帮助测试团队同时朝着这三个目标迈进。
如何实施测试流程改进？
为了实施测试流程改进 Guru99 Bank 项目，测试经理可以遵循 PDCA PDCA（计划-执行-检查-改进）模型是一种四步管理方法，在商业领域用于控制和持续改进流程。每次循环都是一个改进周期，而“行动”步骤的输出则成为下一个“计划”步骤的输入。
💡提示： 每次只针对一个具体问题运行 PDCA 循环。如果循环的目标是单个可衡量的痛点，例如回归执行时间，那么循环完成得足够快，可以在一个版本内看到结果。
步骤 1）计划
计划阶段是设计改进方案的阶段，它分为三个小步骤。
步骤 1.1）确定问题
测试改进过程的第一个活动是 确定 当前项目中出现的问题。该项目中的问题可能会在其他项目中再次发生。解决问题并找出解决方案以避免将来再次发生是测试改进的首要目标。
现在回到项目上来。 Guru99银行网站，您发现任何问题或需要改进的地方吗？请在下方选择。
| 不先生 | 市场问题 | 描述 | 选择 |
|---|---|---|---|
| 1 | 品质 | 顾客仍然发现一些 缺陷 释放后 | |
| 2 | Delivery | 该项目被推迟 | |
| 3 | 团队 | 有些员工没有与其他团队成员合作 | |
| 4 | 技能 | 团队成员缺乏完成任务所需的技能 | |
| 5 | 管理学 | 测试经理没有很好地监控进度，导致一些项目延迟 | |
| 6 | 外场通讯 | 无法与客户持续联系；误解客户的要求 | |
| 7 | Cost | 项目成本超出了设定的预算 |
步骤1.2）确定目标
了解问题所在以及项目中出现的问题。这样才能确定改进点和需要优先关注的测试阶段。
假设你已经确定测试执行阶段花费的时间太长 许多 完成测试需要花费时间和成本。测试能否更快、更便宜？这个问题就成了本轮测试的目标。一个有效的目标应该用数字和截止日期来表示，例如“在下一个版本发布前，将回归测试的执行工作量减少 30%”。
步骤 1.3）定义改进措施
根据既定目标，制定改进措施。这些措施应循序渐进地实施，因为立即改变一切是不现实的。
例如，为了使测试更快、更便宜，可以采取以下措施。
在上面的例子中，选项 A 和 B 都能使测试更快、更便宜。选项 C 也能加快测试速度，但成本更高，因为经验丰富的测试人员薪资更高。正是这种权衡取舍，使得每个候选方案都必须以目标为导向，而非凭直觉判断。
步骤2）执行
您已经确定了改进要点。现在需要制定一个实施计划。该计划必须回答以下问题。
- 需要实施哪些改进措施？实施顺序是什么？
- 计划何时必须完成？
- 要实现该计划，需要完成哪些步骤？
- 每个步骤由谁负责，以及如何确认完成？
执行改进措施
计划一旦制定，就必须执行。改进活动可能会干扰正在进行的测试工作，因此测试经理必须支付相关费用。 关注我们 为了他们 避免不必要的 后果。
考虑以下情景。在…… Guru为了使测试更快更便宜，您决定在 99 Bank 项目中使用 自动化测试 用这种方法代替了大量的手动回归测试。实施该方法后，生产效率显著提高。
步骤 3）检查
在检查步骤中，您需要执行三项操作。
- 评估 效率 测试改进措施
- 衡量方法 高效 解决方案是
- 分析它是否可能是 改善 进一步
本阶段的目标是确认改进措施是否已成功实施，并评估计划中设定的目标是否已实际实现。
进行该评估的最佳方法是： 度量指标对于成功的组织管理至关重要。测试经理收集数据，并用这些数据来衡量生产力、质量和成本等参数。
例如，在项目应用自动化之前，测试效率是 每人每小时 10 个测试用例自动化实施后，生产率测量结果为： 每人每小时 20 个测试用例.
但伴随这种收获而来的，却出现了一个意想不到的问题。
在这种情况下，应用自动化 增加 测试的效率固然重要，但测试的质量同样不可忽视。 下降因此，改进措施可能会造成严重后果。 后果 其他地方则不然。在这种情况下，测试工具的选择必须更加谨慎，自动化测试套件的审查也必须像生产代码一样严格。对候选工具进行结构化评估，例如文中描述的方法， Selenium 教程阻止工具仅仅因为流行而被采用。
⚠️警告： 切勿仅凭单一指标来评判改进措施。例如，一项改进措施虽然使执行吞吐量翻倍，但缺陷检测率却降低了，这意味着流程速度更快，但质量却更差。务必将速度指标与质量指标结合起来考虑。
再考虑同样的情景。 Guru99 项目成本已 泛滥 因为团队成员投入了太多精力 很多时间 执行测试用例。通过使用自动化测试工具，您节省了 30 percent 项目成本有所降低。这确实是一个不错的改进，但你的老板期望更高。
因此，您必须不断寻找能够进一步改进测试流程的新解决方案。在这种情况下，其他方案可以节省额外的项目成本。
- 有效管理人力资源，让技能娴熟的测试人员在最能发挥其价值的地方发挥作用。
- 与您的工具和人员配备供应商协商更优惠的商业条款
- 与其自动化重复或低价值的测试用例，不如将其删除。
步骤 4）行动
当改进措施成功实施且目标达成后，测试经理应完成以下活动以完成整个流程。
- 评价 改进活动并吸取经验教训
- 规范 测试管理流程中的改进点
- 更新 政策文件、测试计划模板和标准流程文件
- 确定 这些变更将在下一个项目中何时何地应用？
如果目标未达成，循环不会停止。未达成的目标会连同检查阶段揭示的所有导致行动未达标的原因一起，进入新的计划阶段。
TPI NEXT、TMMi 和 CMMI 的比较
PDCA循环是改进的引擎，但参考模型可以告诉你“更好”的标准是什么。目前常用的模型有三种，但它们之间经常被混淆。
TPI NEXT 这是由 Sogeti 发布的针对特定测试的参考模型。它评估 16 个关键领域，这些领域分为三组，并对应四个成熟度级别：初始级、受控级、高效级和优化级。由于评估是逐个关键领域进行的，因此一个团队在一个领域可能达到高效级，而在另一个领域仍处于受控级。
TMMi由 TMMi 维护 Foundation是一个分阶段的成熟度测试模型，分为五个级别：初始级、管理级、定义级、测量级和优化级。组织只有在满足该级别所有流程领域的要求后，才能达到该级别。
CMMI TMMi 并非测试模型。它涵盖整个开发组织，其分阶段表示法也包含五个成熟度级别：初始级、管理级、定义级、量化管理级和优化级。TMMi 的设计初衷是作为 CMMI 的补充，而非取代。
| 型号 | 适用范围 | 结构 | 成熟度 |
|---|---|---|---|
| TPI NEXT | 仅测试过程 | 16个关键区域分为3组，设有检查点和集群 | 4 — 初始的、受控的、高效的、优化的 |
| TMMi | 仅测试过程 | 分阶段进行，每个阶段都分配了不同的流程区域。 | 5 — 初始阶段、管理阶段、定义阶段、测量阶段、优化阶段 |
| CMMI | 整体发展组织 | 舞台式或连续式表演 | 5（分阶段）—初始阶段、管理阶段、定义阶段、定量管理阶段、优化阶段 |
证明测试流程改进的指标
如果没有数值，检查阶段就无法完成。只需在每个周期前后收集一组小型、稳定的指标即可，并且比较双方必须使用相同的指标定义。
- 测试执行效率 每人小时执行的测试用例数
- 缺陷检测率 (DDP) — 测试中发现的缺陷占所有发现缺陷（包括发布后报告的缺陷）的比例
- 每个执行测试用例的成本 总测试工作量成本除以已执行的测试用例数
- 需求覆盖率 — 至少包含一个关联项的需求 测试用例
- 缺陷修复周转时间 — 缺陷的平均年龄 缺陷生命周期
使用 Guru99 银行的数据是，测试中发现了 180 个缺陷，发布后客户报告了 20 个缺陷，计算方法很简单。
# Defect Detection Percentage and improvement deltas def ddp(found_in_test, found_after_release): return found_in_test / (found_in_test + found_after_release) * 100 def delta(before, after): return (after - before) / before * 100 print("Defect Detection Percentage: %.1f%%" % ddp(180, 20)) print("Productivity gain: %.1f%%" % delta(10, 20)) print("Test cost change: %.1f%%" % delta(50000, 35000))
输出：
Defect Detection Percentage: 90.0% Productivity gain: 100.0% Test cost change: -30.0%
90%的缺陷率意味着每十个产品中仍然有一个缺陷流落到客户手中，因此即使生产率翻了一番，成本下降了30%，质量目标也未能完全实现。正是这种认知，使得团队无法过早地宣布胜利。
常见的测试流程改进错误
大多数改进项目失败的原因在于组织结构而非技术层面。以下错误是导致大多数项目夭折的原因。
- 没有基准线也能进步。 如果在变更前没有人对流程进行测量，就无法证明变更有效。应该在计划阶段而非之后收集基线数据。
- 追求的是成熟度，而不是业务驱动力。 一项证书如果不能降低成本、减少缺陷或缩短交货时间，那就是一项支出，而不是一项改进。
- 一次性改变太多东西。 当五个操作在同一版本中发布时，不会出现回归问题。 trac对他们中的任何一个都适用。
- 将一个失效的流程自动化。 自动化会成倍放大它所应用的任何流程，包括薄弱的测试设计和不明确的准入标准。
- 跳至ping 行动阶段。 一项从未写入测试策略的改进措施 软件测试生命周期 文件会随着发明它的项目团队的消亡而消亡。
- 不包括测试人员。 如果有人事先没有被征询意见，他们总能找到规避的方法。
为了进一步阐述这些想法，请回顾以下阶段： 软件测试生命周期，收紧你的 测试用例 设计，正式化 缺陷管理流程评估 自动化测试 带来真正的回报，看看像这样的工具是如何运作的。 HP ALM 可以保存检查阶段所依赖的指标。
