测试管理 测试左移和开发赋能

Toby Qin · April 21, 2019 · Last by 萝卜 replied at July 31, 2019 · 4421 hits

从事测试开发那么长一段时间,一直不知道怎么去评价和衡量这个职业的目标是什么,超高的自动化测试覆盖率?或者超稳定超包容的自动化测试框架?

怎么才算得上是一个优秀的测试开发人员?上周有机会去听了阿里2天的公开课,好像明白了一些,拿来跟大家分享一下。

内建质量

在微软有一句名言:“质量是设计出来,而不是测出来的。” 当然,这是理想情况,如果产品经理都这么优秀,这个世界早就和平了。

今天我们不说产品经理,我们从测试和开发的角度看,怎么内建质量。

让测试内建质量

为了内建质量,测试同学就要尽可能早地干预开发写bug,让bug死在摇篮里。换句话说就是让开发不要写出可以避免的bug:

  1. 产品,开发,测试应该同时参与需求评审会议,澄清需求,达成共识
  2. 将关键测试点作为需求的一部分,让开发同学交付需求时完成自测

让开发内建质量

从开发的角度看,要提高代码的质量可以有很多种方式:

  1. 提高自测意识,借助单元测试或者质量分析工具
  2. 真正理解需求和技术架构,进行Code Review或者结对编程
  3. 评估代码质量或者bug数量,跟绩效挂钩

排除开发的自身能力问题,80%的bug都是需求理解不准确的问题,如果开发不愿背这个锅,那就甩给产品经理吧。

由此可见,如果测试不想看见这些bug,那么你就要帮产品表达需求,帮开发理解需求。

测试左移

上面我们说内建质量其实已经涉及到了测试左移,例如让QA在参与需求研讨时提出问题,列出测试点其实已经开始在进行测试了。

为什么我们要测试左移呢?因为发现问题的时间越晚,修复的成本就越高。

img

图中橙色线条代表了传统测试发现缺陷的时间,大多数bug都是在功能测试和集成测试时发现的,最后导致的结果就是发布前加班加点,祈祷不要有bug漏到生产环境。

如果我们能把测试活动向左移动,那么就意味着修复成本大幅下降。

img

但是谈何容易?想要把大部分测试点放在单元测试环境完成,非常依赖成熟的开发环境和极其资深的开发人员。

在阿里是这样实践的,让测试给开发赋能。

开发赋能

从字面上解释就是,测试同学给开发赋于一定的能力,让他们有能力去完成测试,比如:

  1. 降低测试门槛
  2. 使用测试工具(自动化)
  3. 获取测试数据
  4. 培养测试意识

举个例子,开发同学在完成需求代码后,可以点击一个按钮得到测试数据,再点击一个按钮验证测试覆盖点,喝杯咖啡后就可以看到测试报告。

从上面这个例子看,开发同学其实他并不需要懂测试数据的设计,自动化测试的开发,测试报告的编排,但是他依然可以快速完成需求测试(门槛低),只要他养成习惯(培养意识)。

那么你就会说,这对测试的同学要求是不是很高啊?对啊,回到开篇的问题,如何评判一个测试人员的能力?在我看来就是评判他给开发和团队赋能的能力。在阿里是这样,在微软和谷歌也是这样。

一个优秀的测试人员将测试左移时,并不会将负担转移给开发。相反地,而是帮开发写出更高质量的代码,更高效率地交付需求。

那么测试能左移到什么程度呢?比如让开发在Coding时就发现问题,或者还没Coding就发现问题,那应该是极好的。

img

怎么做到呢?刚才已经说过了,测试即需求,把bug扼杀在摇篮里。

实践方法

想实践测试左移可以有很多种方法,每个组织需要根据实践情况进行裁剪和调整。

  1. 参与需求评审,帮助开发理解需求
  2. 参与架构、设计分析,提早预防问题
  3. 践行BDD,TDD
  4. 单元测试提案,接口测试提案
  5. 提供模拟数据能力,测试工具
  6. 制定提测标准,拒绝低质量代码
  7. 回归测试自动化
  8. 静态代码分析,单元测试覆盖率

测试左移的概念给整个测试角色带来了巨大的转变。软件测试不仅仅是“发现bug”,而是致力于“尽可能早的检测和预防bug”。

参考资料

关于作者:

Toby Qin, Python 技术爱好者,目前从事测试开发相关工作,转载请注明原文出处。

欢迎关注我的博客 https://betacat.online,你可以到我的公众号中去当吃瓜群众。

Betacat.online

共收到 21 条回复 时间 点赞

测试左移需要测试人员的水平达到什么高度啊。
公司领导想左移,但自身能力不够,好尴尬。
好想能够左移!

blog很棒

中国大部分中小型公司,想要测试人员的水平比开发人员还要高一个水平,有点异想天开。
除了BAT和类似的大厂之外,普通公司就别这样想了。

单纯的考虑前端(web、App)的话,除了参与需求评审,细化、拆分需求,还有哪些方式进行测试左移为开发赋能?

“将关键测试点作为需求的一部分,让开发同学交付需求时完成自测”对于这点,作者的实践方法是怎样的,除了积极的沟通,是否有一些可移植的规范或者套路呢

测试转开发就完美解决这种问题了

有启发,正在一步步朝这个目标努力中。

测试左移测试提早介入有何区别?
如没区别,只能在此吐槽10万次;

狼图腾 回复

不一定要转开发,你可以给开发甚至整个团队写一些工具,能帮忙他们为测试服务。

Toby Qin #10 · April 22, 2019 作者
JackYujunjie 回复

让开发有能力帮你做测试,降低测试的门槛从而愿意帮你做测试。比如超级傻瓜的测试数据获取,哪里不会点哪里的测试工具,平时多观察和话聊开发的痛点,如果你不漂亮就偶尔请喝果汁也行。

很棒,多谢分享!

车轱辘话来回转

徐汪成 回复

不用加这句“除了BAT和类似的大厂之外”也没毛病,‘开发同学在完成需求代码后,可以点击一个按钮得到测试数据,再点击一个按钮验证测试覆盖点,喝杯咖啡后就可以看到测试报告’ 这种和共产主义理想国差不多。很多说起来很有道理,但是没法落地

大厂在近些年做了很多测试左移的探索,以我所处的环境为例,在讨论的时候就有提到怎么让业务在有保障的前提下自我迭代,而达到研发自交付的效果,在这里我们做了静态代码扫描,接口测试自动化,环境一体化,预演方案,线上引流回归,全链路压测,线上精准监控等测试工程化的措施,这里的很多工具和平台不是全部为我们自己负责业务的测试团队开发的,大部分是引用,有就拿来用,投入应用->得到数据-分析效果-赋能团队,建立起来后迭代版本时研发只要提交了代码就有一体化的质量保证服务,测试人力的涉入就可以大大减少,但我就说句站在个人立场的话,等这些都做得很完善的时候,也就是你差不多也退场的时候了,比较悲观的思考是:测试做到头就是自我淘汰自我毁灭了

kuroky 回复

也不是没办法落地,只是非BAT这类的中小公司,落地成本偏高,因为这个必须测试技术和管理上也得有支撑。而现在的普通中小型公司大多并不太愿意花太多成本在测试上,虽然已经比以前改善了很多了。

Toby Qin #16 · April 23, 2019 作者
hellohell 回复

左移和介入出发点是不一样的,介入更多是参与,左移更多是实施。

terrychow 回复

淘汰自己是不可能的,但会淘汰不合适这种模式的人。测试并不会消亡,只是换了一种存在方式。

这才是理想的 QABP 模式啊。

云翼风希 回复

大公司成本就低了?就会投入更多的预算?不是抬杠,但这种理想化的思想和“画大饼”差不多,还是要脚踏实地,不要去猜想“别人家的孩子”。

kuroky 回复

提交代码的时候,自动触发单元测试和脚本测试,不全是绿色,拒绝提交直接打回撒。说实话,这个和公司文化有关系,公司不支持,还是别想了

terrychow 回复

脚本需要不断更新,维护也需要人力,新的功能手工测试也是需要的。只要软件需要迭代,测试的这方面工作也要做的。和开发一样啊

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up