一、引言

在现代商业和技术领域，投资回报率（Return on Investment，ROI）一直是被关注的焦点之一。企业和项目经理们都追求在有限的资源和时间内实现最大的 ROI，以确保他们的投资和决策是明智的，有助于组织的成功和可持续发展。
在软件开发和项目管理领域，测试是确保产品质量和用户满意度的重要环节。然而，测试本身也需要投资，包括时间、人力和技术资源，而在当下企业追求人效的前提下，这些资源也是极其有限的。因此，我们也必须深入探讨测试活动如何与 ROI 相关联。在本文中，我们将探讨三个关键问题，包括测试计划制定的价值，测试成本和质量风险之间的平衡，以及项目提效手段，而这些问题都与 ROI 紧密相关。

二、测试计划

有人说，现在都是敏捷开发了，项目都是小步快速迭代，不需要做测试计划，也没时间做测试计划。事实真是这样吗？
在早期瀑布模式下，测试计划是测试阶段极其重要的一环，测试计划文档也是很重、很庞大的一份文档。现在敏捷盛行，确实很少再去制定传统意义上的测试计划文档了，但绝不意味着测试计划失去了其意义。古人云，凡事预则立不预则废，测试计划依然非常重要，只是形式上变得更轻盈，可以随项目灵活调整。
何谓测试计划？
测试计划规划了具体的测试活动和任务，包括测试的具体目标、测试范围、测试进程、测试资源分配、测试时间表、测试工具和技术、风险评估等内容。简单来说就是具体回答 “测什么，怎么测” 的问题。
假如我们要对用户登录模块做测试，我们需要决定测什么、不测什么，是只测 PC 浏览器端就行，还是移动端也需要考虑；除了功能需求，还有哪些非功能需求需要考虑，兼容性要覆盖哪些浏览器；同时，由于不可能穷尽测试，而且测试的时间和资源都是有限的，所以必须有所取舍，进行更有针对性的测试以提升 ROI；明确了范围，我们还需要明确先测什么后测什么，核心重要功能优先保障；对于测试资源分配，就是要明确谁来测，这涉及到结合人员特点和素质来分配最适合的工作，用哪套环境测，是共享环境还是独享环境，抑或是直接在线上环境测，谁来搭建环境；测试时间表要求我们尽可能拆分测试时间，给出明确的时间节点；而对于风险评估，因为计划赶不上变化，通常很少有整个测试过程是完全按照原本测试计划执行的，过程中可能存在需求变更、测试工作量预估不准、人员变动等情况发生，所以，在制定测试计划时，也要预估整个测试过程中可能存在的潜在风险，以及当这些风险发生时的应对策略，做到心中不慌，有条不紊地应对这些挑战。
谈到这里，我们就能够意识到，测试计划的价值非常大，并且事实上与敏捷开发方法并不冲突。提前制定测试计划，可以在以下方面产生价值：
①.测试方向和目标：确保整个产研团队对于测试的范围、重点和优先级有一致的认识，防止测试执行过程中偏离目标，并且确保测试执行的全面性，提高交付质量；
②.项目进度把控：合理分配测试资源，在后续实施测试过程中，确保测试活动能够按计划正常推进；也通过提供测试进度、缺陷报告、关键问题等信息，确保整个产研团队对测试活动的状态有清晰的了解；
③.风险管理：帮助团队识别潜在风险，提前采取行动措施来降低或者规避风险；
④.为后面的项目复盘提供依据；
最后说明一点，测试计划不一定是要有正式文档。在敏捷背景下，根据项目大小不同，测试计划可以是单独文档、也可以作为 xmind 测试用例的附属内容、可以写在一张便签纸上、甚至更小的项目直接心中有数即可。核心是让测试执行过程明确、有序。为了让后续的测试过程 ROI 更高，制定测试计划的时间投入绝对值得。

三、测试成本和质量风险

“花了这么长时间做了大范围的测试和回归，还是有重大缺陷漏出到线上”，我们可能经常会有这样的感慨，投入很多，但质量风险依然还是发生，这是典型的测试 ROI 不足的表现。
首先我们要明确一点，测试资源不足是常态，好钢要用在刀刃上，如何花最少的成本来披露最多的问题和风险，也就是如何提高测试活动的 ROI，这属实是一门技术活。下面笔者列举几个方面供大家参考。
①.测试范围圈定：如果本次提测所改动代码的影响面经过了准确评估，那就可以做到精准测试，否则做的大量非影响范围内的回归测试成为无用功，自然无法提升 ROI。诚然，项目经验可以极大程度上提升影响范围分析的准确性，有技术能力的同学一般也会通过 CodeReview 以及 CodeDiff，精准判断影响范围；当然，与产研同学进行细致沟通，抑或在流程上做一些保障，比如提测单附上完整的修改点及影响面，也是可以推动的方向。
②.风险评估：明确哪些功能/模块/业务流程对最终产品的质量目标最为关键，重点/高风险内容优先、深入测试，普通/低风险内容次优、适度测试。业界其实有个说法叫 RBT（基于风险的测试），如何选择测试重点，安排测试强度和优先级，使得风险处于可控状态，这就是 RBT 需要考虑的问题。当然，基于风险的测试策略最好与产研侧达成共识。有了风险评估，我们也能对测试过程进行优化，实现重大缺陷尽早暴露。针对功能模块的风险评估，笔者认为可以分别考量以下维度：

③.自动化测试：老生常谈的提升 ROI 手段，可以用于冒烟或者回归测试（如各个团队在做的 httprunner 接口自动化、diff 测试等），以及特定任务自动化提效（比如数据构造自动化）。自动化测试有其适用场景，在做之前一定要明确我们的目标是提升 ROI，而不是为了秀技术、摆花架子。当然，自动化测试并非是一定要自己开发，通过引入工具和技术，比如广告引擎测试经常使用的 tcpcopy 导流测试，能够极大提升 ROI。
④.迭代开发和增量测试：这正是敏捷开发所遵循的模式。如果一个项目很大，集中测试风险自然就高，作为测试，我们也应尽力推动项目拆解细化，分批提测，流水线式交付，自然也能提升 ROI。
⑤.协作优化：根据不同项目和产研团队特点建立协作模式，可以制定 bug 分级修复时限、每日站会等、扫清测试过程中影响进度的拦路虎，避免测试过程中的无效等待消耗时间成本。当然，必要情况下需要让产研测充分了解测试资源的限制和风险，以便及时采取行动，比如 PM、RD 共同参与测试。

四、项目提效

正如前面所讲，提高测试工作的 ROI，进行项目提效，手段可以有很多，绝不仅限于技术方面。乔梁在他的《持续交付 2.0》一书中提到了 “效率竖井”，各个环节和部门看上去繁忙而高效，但总体交付效率却很低。

为什么会导致这样的问题发生？往往是由于过度局部优化。因为局部工作优先级不同、批量式的工作移交等原因导致不同部门和职能间总是发生相互等待，而想要给项目提效，不仅在于某一工种内部的效率提升，也在于尽可能消除这些等待环节。持续快速交付价值的能力，是研发效能的核心定义，项目提效应该充分考虑这个核心。
我们可能经常遇到以下几个影响项目交付效率和质量的问题：
①.需求不明确，产品、开发和测试工作分离，尾端介入，不能尽快熟悉进入状态；
②.信息不流通，对于需求&设计变更，功能修改&代码重构等信息，测试人员不能及时了解；
③.团队无法做到有效的持续集成和持续发布，环境问题多，每次发布的版本质量不可控；
④.阻塞问题多&bug 修复慢&修复质量不佳，导致等待时间拉长、回归成本增加；
⑤.自动化测试体系不完善，重复繁琐的回归测试成为严重的工作负担；
⑥.没有合适的测试工具，难以快速的完成测试数据构造等工作，大量无价值的内容需要手工完成；

我们知道，流程、组织、技术是测试经常考虑的三个优化方面，作为 QA，我们推动项目提效也可以分别从这三方面着手优化。

五、最后

前面我们描述了很多不同类型的测试工作开展，虽然测试活动目前为止还没有做到非常扁平，但已然渗透到产研的各个阶段，这些工作都有利于测试 ROI 的提升。那 ROI 提升之后呢？每个测试人，每个质量团队，其实都需要问一个问题，测试的价值究竟如何体现。我们所提的 bug 量能充分体现价值吗？
在笔者看来，测试价值的终极体现，是团队赋能。

在需求层面，测试能够输出什么样的价值？
①.基于业务上下文背景进行需求澄清，判断 PM 提出的需求是否具备用户价值；
②.需求不明确时，帮助业务梳理现有逻辑，提出预期需求；
③.不同需求背景下，补充验收标准，提出周边支撑性需求；
④.针对界面交互和用户体验提出改进建议；
在实现层面，测试能够输出什么样的价值？
①.参与技术讨论，共同制定技术架构设计；
②.基于风险评估及优先级，提供测试用例；
③.提供测试工具、脚本、数据，帮助团队在各环节提效；
④.培养测试意识，测试文化深入团队内部；
在组织层面，测试能够输出什么样的价值？
①.通过质量分析及团队效能分析，找出问题及推进改进；
②.提前暴露风险，进行风险预警，通过行动消除风险；
③.业务知识的积累、沉淀，成为领域专家；
以上，诸君共勉。