自动化测试如何创造业务价值？

本文是自动化测试系列的第五篇文章，这篇文章我想聊聊自动化测试如何创造业务价值。

这篇文章的灵感，来自前几天知识星球社群内部分享时候的一个topic，有同学问到做自动化测试的价值如何体现。

我在上一篇文章《聊聊自动化测试的度量指标》中的开篇词提到过一个观点：

脱离数据支撑谈价值多少有点底气不足，但脱离自动化的初衷和背景谈质量数据度量，也有些南辕北辙。

在分享中，对于自动化测试的价值如何体现，我的思考和观点主要有如下2点：

• 基于团队内部，从解决问题角度出发的技术落地实践和数据度量；

• 基于跨团队合作，从KPI/OKR角度,用度量的数据来支撑你的价值传递；

接下来我会基于上述两点来分开阐述我的观点和思考。

团队内部，解决问题

前面的自动化测试系列文章提到过，不同公司不同技术团队对于开展自动化的目的各有不同，常见的目的有下面几点：

• 测试数据准备耗时长，为了
  提升造数据的效率
  而做自动化测试；

• 项目上线之前的核心业务链路回归，为了
  提升回归测试效率
  ，这也是一种上线前的check手段；

• 提测前为了
  快速验证提测质量
  ，作为一种
  冒烟测试手段
  提升效率，同时这也是一种
  测试左移的实践
  ；

• 团队大业务线多，通过统一框架和协作规范来提升测试团队协作效率，
  减少造轮子，避免资源内耗浪费
  ；

当然还有其他目的，总结一下，做

自动化测试的目的主要是降本增效。即通过技术手段，提升测试过程效率和团队协作效率，新增测试回归验证手段，降低重复性工作投入成本

。

其实无论是出于什么目的，开展自动化的本质，一定是有痛点影响到了项目交付质量或者效率。

开展自动化，首先是为了解决问题，度量指标是为了便于评估开展这件事的投入产出是否符合预期，以及支撑价值传递。

用一个朋友的话讲：

最怕的是那种还没开始做就喊着我要做自动化测试平台，用什么高大上的技术的人。

我希望我团队里的同学，做自动化是自发的，想解决自己工作中遇到的问题，先让自动化run起来。

界面好不好看用什么工具不重要，重要的是问题有没有解决，有没有提升效率，解决真实的问题。

跨团队合作，价值传递

接下来聊第二个观点：基于跨团队合作，从KPI/OKR角度，用度量的数据来支撑价值传递。

自动化测试对测试团队来说，最直接的

显性价值是替代手工重复工作，解放人力，保障回归质量，提升测试过程效率

。

而

解放的人力，可以去做更多更有创造性的事情，这也是自动化测试的隐性价值

。比如：

• 尝试探索性测试；

• 提升测试人员的技术和实践能力；

• 加深对需求和业务的理解，有所沉淀；

• 研发测试过程改进和机制/技术优化，提升协同效率；

还有一点可能很多同学会忽略，就是

自动化测试对团队带来的放大价值

。主要体现在几个方面：

• 自动化测试加入到CICD流水线中，提升持续集成和交付能力；

• 脚本的可复用性会提高脚本对应功能点的覆盖率，能降低很大的人力成本；

• 建立并维护好测试用例/测试脚本库，可以培养新加入的同学以更快的速度形成战力；

很多时候我们思考问题都会习惯从技术角度出发，实际上

技术是为业务目标达成提供支撑和效率的工具

。

对企业来讲，业务是最直接的变现逻辑和渠道，

业务目标追求的是更低成本+更高效率，来保障目标达成

。

业务发展遇到了痛点（技术导致的业务目标未达成），就想办法利用技术手段解决业务的痛点。

所谓的自动化测试创造的业务价值，其实就是

自动化测试的初衷和本质：降低成本+提升效率

。

自动化测试可以通过间接的方式支撑业务目标的达成，但并不是说有技术就能创造正向的价值。

技术要创造业务价值很简单，只需要遵循这几点：

• 发现业务痛点；

• 找到合适的方案；

• 用更低的成本更高的效率更好的解决业务痛点；

我在前面的文章《自动化测试如何实施落地》中提到了关于项目落地运营要注意的事项：

业务运营：解决了业务什么痛点，对业务目标达成的促进；

技术运营：用户体验、交付效率、质量提升、用户满意度；

本质一直没有变化，就是找到痛点，用合适的方案解决问题。

解决问题的过程中，用数据指标来度量解决问题的成本和效率，不断修正过程。

最后，用数据来支撑你的价值传递。