《在每一步中嵌入质量 —— 从测试到持续改进》—— 博客系列第四部分

​​

我们已涵盖的内容及后续内容

到目前为止，我们已经探讨了可靠质量计划的基础要素、设计方案与文档管理、风险和依赖关系，以及最小可行产品（MVP）和故事映射。

现在，我们将进入项目质量的下几个关键支柱：

• 明确测试责任 —— 确定由谁在何时测试什么内容，以确保对所有测试类型都有明确的责任归属。
• 测试左移 —— 在开发早期就集成测试，以便在问题易于解决且成本较低时发现它们。
• 就绪定义（DoR）和完成定义（DoD） —— 设置严格的标准，防止不完整或低质量的工作进入或退出迭代周期（sprint）。
• 现实可行的迭代计划 —— 为测试、评审和意外挑战分配时间，以在避免最后时刻匆忙赶工的情况下保持质量。
• 持续反馈循环 —— 利用演示、验收测试和回顾会议来推动持续改进，并防止出现期望偏差。

让我们继续在项目的每个阶段都融入质量因素。

1. 测试流程与责任：谁在何时测试什么内容？
   11.1 不同的测试类型

在现代 IT 项目中，存在各种各样的测试类型：单元测试、集成测试、API 测试、端到端（E2E）测试，有时还有负载测试和安全测试。如果不加以注意，人们可能会认为 “测试人员” 或 “质量保证（QA）人员” 会处理所有这些测试。最好明确责任归属：

• 单元测试：通常是开发人员在编写代码时同时完成的任务。
• 集成测试和 API 测试：这是共同的责任，但质量保证（QA）人员要发挥明确的作用，以确保涵盖了正确的测试场景。
• 端到端（E2E）测试和链式测试：可以是技术性的（例如使用 Cypress 或 Selenium 工具）和功能性的。要就由谁编写、维护和运行测试脚本达成一致。
• 负载 / 性能测试：通常由专业人员处理，因为这需要特定的工具和专业知识。一个常见的错误是将这项任务交给开发人员，低估了所需的专业知识。风险在于管理层可能会轻信性能测试结果，尽管这些结果可能无法准确反映未来系统的实际运行情况。
• 安全测试（渗透测试）：由于其复杂性，通常会外包给专业人员，但团队仍然必须能够解读和处理测试结果。

​​

11.2 将测试视为不可或缺的一部分

“测试左移” 的理念意味着：尽早进行测试，这样你就能在问题易于解决且成本较低时发现它们。只有当团队将测试视为项目不可或缺的一部分，而不是等到 “功能完成后” 才进行测试时，这一理念才能发挥作用。所以在迭代周期（sprint）中为测试规划时间，并确保每个用户故事都有可测试的验收标准。有助于实现测试左移理念的做法是在你的流程管道（例如 SonarQube）和开发人员的开发环境（IDE）（例如代码检查工具）中设置自动化控制。

提示：关于测试自动化有很多内容可以探讨，这里暂不展开。例如可以参考《失败的测试自动化项目的弊病》和《自动化测试的利器 Checkovs》这两本书。

测试流程与责任的快速有效方法：

• 明确测试责任归属
• 测试左移 —— 在开发早期进行测试
• 确保每个用户故事都有可测试的验收标准
• 在持续集成 / 持续交付（CI/CD）管道中自动化质量检查

• 将测试集成到开发环境中

• 就绪定义（DoR）：用户故事何时可以纳入迭代周期（sprint）？

12.1 就绪定义（DoR）的作用

就绪定义（DoR）有助于你确定一个用户故事何时可以开始处理。一个尚未 “就绪” 的用户故事可能仍然缺少明确的验收标准、设计方案，或者来自外部方的输入等。通过使用就绪定义（DoR），可以防止团队在处理到一半时才发现关键信息缺失，从而导致工作停滞和时间浪费。

12.2 示例标准

• 业务价值已明确定义。
• 用户故事已分解为可管理的规模（不是超大型的）。
• 所需的设计方案和技术输入已准备好。
• 任何依赖关系或阻碍因素都已识别出来。

只有当所有这些标准都满足时，团队才会对其进行估算（故事点数或大致规模），并且该用户故事才能进入迭代周期（sprint）。

另一个标准是，就绪定义（DoR）应符合 INVEST 标准。

1. 完成定义（DoD）：某件事何时才算真正完成？

13.1 为什么完成定义（DoD）至关重要

你可能有过这样的经历：开发人员说 “我完成了”，但结果发现他只是编写了代码，却没有进行测试或编写文档。然后就会产生困惑：“完成” 真的意味着完成了吗，还是仍然有工作需要做？完成定义（DoD）能让这一点变得非常清晰。

13.2 完成定义（DoD）标准示例

• 代码已根据分支策略进行了审查和合并。
• 单元测试已编写并成功通过了流程管道的测试。
• 集成测试或端到端（E2E）测试（如果相关）已通过。
• 文档（例如在 Confluence 中）已更新。
• 功能已进行演示并得到产品负责人的认可。

只有当所有这些条件都满足时，你才能说这个用户故事 “完成了”。这听起来可能很严格，但它能确保质量的一致性，并防止你在之后不得不收拾残局。

请注意，完成定义（DoD）意味着你真的完成了，而不仅仅是一系列要求！

1. 高效的迭代周期（Sprint）：实际地进行规划并为测试留出空间

14.1 迭代周期（Sprint）规划

一个常见的问题是开发团队在迭代周期（Sprint）中承担了过多任务，导致时间不足。他们假设处于一个理想的世界，每个人每天的工作效率都一样。但在现实中，会有会议、不可预见的问题以及假期等情况。一个建议是始终预留一定的缓冲时间，并明确规定应该为测试和（代码）评审预留多少时间。例如，可以使用这样一个经验法则：将用户故事点数的 20% 用于保证质量。

14.2 始终包含测试任务

对于每个用户故事，都应该有单独的单元测试、集成测试、端到端（E2E）测试以及可能的其他测试类型的任务。这样，在迭代周期（Sprint）的压力下，测试任务就不会被遗忘。如果你把所有任务都塞进一个 “待办事项” 中，那么很可能测试任务会被排在最后，一旦截止日期临近就会被放弃。

就绪定义（DoR）、完成定义（DoD）与高效迭代周期（Sprint）的快速有效方法：

• 确保用户故事有明确的验收标准
• 将用户故事分解为可管理的规模
• 要求进行代码审查和自动化测试以完成任务
• 在迭代周期（Sprint）规划中预留专门的测试时间

• 定义单独的测试任务以避免最后时刻匆忙赶工

• 定期演示和验收测试：让利益相关者持续参与

15.1 将迭代周期（Sprint）演示作为反馈时刻

迭代周期（Sprint）演示不仅仅是 “自豪地展示你所构建的成果”。最重要的是，它是一个获取反馈的时刻。利益相关者可以立即指出解决方案是否符合他们的期望。这样你就能避免在进行了六个迭代周期（Sprint）后才发现走错了方向。

​​

15.2 验收测试

作为演示的一部分（或在演示之后立即进行），你可以安排验收测试。这可以是正式的（基于定义的测试场景），也可以是非正式的（与产品负责人一起在应用程序中进行操作测试）。其目的是立即了解所有功能是否按约定正常运行。如果需要进行调整，你可以在后续的迭代周期（Sprint）中及时进行处理。

1. 坦诚的回顾会议：学习型团队的秘诀

16.1 开放和安全的氛围

只有当团队感到能够安全地分享错误并将关键问题摆到桌面上时，回顾会议才具有价值。营造一种氛围，让人们可以放心地说 “我们在这里确实判断失误了” 或者 “我对与 X 部门的沟通感到很沮丧”。只要反馈是建设性的，它就会帮助你的项目以及你的团队成长。

16.2 制定具体的行动要点

一个常见的陷阱是回顾会议以一系列模糊的改进措施结束（比如 “我们需要更多地进行测试” 或者 “我们需要更好地沟通”）。要使其具体化：你究竟要改进什么，由谁负责，以及我们何时再次对其进行评估？通过明确行动要点及其负责人，你可以确保回顾会议不仅仅是一个空谈的场所，而是推动改进的引擎。

演示与回顾会议的快速有效方法：

• 使迭代周期（Sprint）演示成为双向反馈循环
• 集成验收测试以便立即进行验证
• 将回顾会议转化为切实可行的改进措施

结论：切实执行的质量计划是成功的指南针

在这份全面的指南中，我们已经看到，质量计划远不止是一系列步骤。它是一个涵盖 IT 项目整个生命周期的整体框架。我们从定义利益相关者开始，接着深入探讨了符合 SMART 原则的非功能性需求，精心制定了清晰的开发流程（持续集成 / 持续交付（CI/CD）、分支管理、代码审查），最后以不可或缺的回顾会议作为结尾，这些回顾会议不断地提升团队的能力。

关键要点有哪些呢？

• 让合适的人员参与进来，并确保了解他们的意见和利益（利益相关者分析）。
• 收集需求（包括非功能性需求）并使其符合 SMART 原则，以便每个人都明白什么才是 “足够好” 的标准。
• 创建一个清晰的开发和测试流程，并明确每种测试类型的责任归属，从而在每一步中都嵌入质量因素。
• 使用就绪定义（DoR）和完成定义（DoD）来避免工作在未准备好的情况下进入迭代周期（Sprint），或者在待办事项中处于未完成的状态。
• 通过演示、验收测试和回顾会议定期进行沟通，以便不断学习和调整。

如果你将所有这些要素整合到一个易于理解且得到支持的质量计划中，你就为一个成功的 IT 项目奠定了基础。这不仅是因为你能够更快更好地交付成果，还因为它能让你的团队更具自我认知。他们知道对自己的期望是什么，在遇到困难时可以选择哪些路径，以及如何共同持续改进。

这就是切实执行的质量计划的力量：它既是指南针，也是安全网。你有了明确的方向，同时也能确定可以尽早发现问题并解决它们。这样，你不仅能开发出优秀的软件，还能打造一支成熟、敏捷的团队，随时应对任何挑战。

总结

希望通过这份全面的指南，为你提供了一个实用且详细的框架。如果你有自己的补充内容或经验，请与你的团队或所在组织分享。每个环境都是不同的，正是通过知识的交流，你才能将质量计划完善成真正适合你所处环境的工具。

想要产生真正的影响吗？那就从制作利益相关者矩阵和符合 SMART 原则的非功能性需求列表开始吧！

如果你对如何引入最优质量计划有疑问，请随时通过邮件 qa@the-experts.nl 与我们联系。

‍