ROI引领测试效能：计划、平衡与价值输出

本文链接：https://blog.csdn.net/m0_67696270/article/details/134319438

在现代商业和技术领域，投资回报率（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》一书中提到了“效率竖井”，各个环节和部门看上去繁忙而高效，但总体交付效率却很低。