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

在现代商业和技术领域,投资回报率(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提出的需求是否具备用户价值;

②.需求不明确时,帮助业务梳理现有逻辑,提出预期需求;

③.不同需求背景下,补充验收标准,提出周边支撑性需求;

④.针对界面交互和用户体验提出改进建议;

在实现层面,测试能够输出什么样的价值?

①.参与技术讨论,共同制定技术架构设计;

②.基于风险评估及优先级,提供测试用例;

③.提供测试工具、脚本、数据,帮助团队在各环节提效;

④.培养测试意识,测试文化深入团队内部;

在组织层面,测试能够输出什么样的价值?

①.通过质量分析及团队效能分析,找出问题及推进改进;

②.提前暴露风险,进行风险预警,通过行动消除风险;

③.业务知识的积累、沉淀,成为领域专家;

以上,诸君共勉。

总结:

感谢每一个认真阅读我文章的人!!!

作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。

视频文档获取方式:

这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方小卡片即可自行领取。

相关推荐
钱钱钱端9 小时前
【压力测试】如何确定系统最大并发用户数?
自动化测试·软件测试·python·职场和发展·压力测试·postman
测试199810 小时前
外包干了2年,快要废了。。。
自动化测试·软件测试·python·面试·职场和发展·单元测试·压力测试
qq_4337169515 小时前
测试分层:减少对全链路回归依赖的探索!
自动化测试·软件测试·功能测试·测试工具·回归·pytest·postman
qq_4337169516 小时前
Postman断言与依赖接口测试详解!
自动化测试·软件测试·功能测试·测试工具·mysql·接口测试·postman
程序员小雷1 天前
软件测试基础:单元测试与集成测试
python·功能测试·selenium·测试工具·单元测试·集成测试·压力测试
霍格沃兹测试开发学社测试人社区1 天前
软件测试学习笔记丨Vue常用指令-条件渲染(v-if)
软件测试·测试开发
测试老哥1 天前
需求不明确时如何设计测试用例?
自动化测试·软件测试·python·功能测试·测试工具·职场和发展·测试用例
霍格沃兹测试开发学社测试人社区2 天前
软件测试学习笔记丨Vue学习笔记-基本介绍
软件测试·vue.js·笔记·测试开发·学习
杰仔正在努力2 天前
Jmeter5.X性能测试
jmeter·压力测试
&1=12 天前
Charles简单压力测试
压力测试·charles