Java教程

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

本文主要是介绍自动化测试如何创造业务价值?,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

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

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

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

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

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

  1. 基于团队内部,从解决问题角度出发的技术落地实践和数据度量;
  2. 基于跨团队合作,从KPI/OKR角度,用度量的数据来支撑你的价值传递;

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

 

团队内部,解决问题

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

  1. 测试数据准备耗时长,为了提升造数据的效率而做自动化测试;
  2. 项目上线之前的核心业务链路回归,为了提升回归测试效率,这也是一种上线前的check手段;
  3. 提测前为了快速验证提测质量,作为一种冒烟测试手段提升效率,同时这也是一种测试左移的实践
  4. 团队大业务线多,通过统一框架和协作规范来提升测试团队协作效率,减少造轮子,避免资源内耗浪费

当然还有其他目的,总结一下,做自动化测试的目的主要是降本增效。即通过技术手段,提升测试过程效率和团队协作效率,新增测试回归验证手段,降低重复性工作投入成本

 

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

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

用一个朋友的话讲:

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

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

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

 

跨团队合作,价值传递

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

自动化测试对测试团队来说,最直接的显性价值是替代手工重复工作,解放人力,保障回归质量,提升测试过程效率

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

  • 尝试探索性测试;
  • 提升测试人员的技术和实践能力;
  • 加深对需求和业务的理解,有所沉淀;
  • 研发测试过程改进和机制/技术优化,提升协同效率;

还有一点可能很多同学会忽略,就是自动化测试对团队带来的放大价值。主要体现在几个方面:

  • 自动化测试加入到CICD流水线中,提升持续集成和交付能力;
  • 脚本的可复用性会提高脚本对应功能点的覆盖率,能降低很大的人力成本;
  • 建立并维护好测试用例/测试脚本库,可以培养新加入的同学以更快的速度形成战力;

 

很多时候我们思考问题都会习惯从技术角度出发,实际上技术是为业务目标达成提供支撑和效率的工具

对企业来讲,业务是最直接的变现逻辑和渠道,业务目标追求的是更低成本+更高效率,来保障目标达成

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

所谓的自动化测试创造的业务价值,其实就是自动化测试的初衷和本质:降低成本+提升效率

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

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

  • 发现业务痛点;
  • 找到合适的方案;
  • 用更低的成本更高的效率更好的解决业务痛点;

 

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

业务运营:解决了业务什么痛点,对业务目标达成的促进;

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

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

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

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

这篇关于自动化测试如何创造业务价值?的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!