扫码阅读
手机扫码阅读

聊聊持续自动化的价值与阻碍

29 2024-01-31

这是鼎叔的第五十七篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。

标题中的持续自动化不只指测试,也包含构建,部署,发布等任务。敏捷团队要确保每次迭代完成时都有可工作的软件,随时可以发布最新产品,这个目标的达成有赖于自动化。这篇文章详细聊聊实施持续自动化有哪些价值,以及面临的各种阻碍。

PART 1 持续自动化的价值

为什么需要自动化?大家很容易想出一系列的理由。这里将列举一些持续自动化实践中容易被忽视的思考。

一 缩短手工测试的耗时

当被测系统(SUT)越来越复杂,软件规模越来越大,手工测试全部功能的耗时会越来越长,甚至会指数级增长。

对于每日持续回归的测试策略,手工测试是不可能完成的任务。

但如果没有一套完整的回归自动化拦截网,测试人员需要分心在基础质量保障上,这些基础测试也需要花费大量时间,带来日益增长的挫折感和枯燥感。不断增加的技术债务也可能导致测试人力成本的增加。

没有频繁的测试检测,代码设计也可能越来越不利于可测性。

相信大家清楚,为各种复杂的用户场景手工创建测试数据,是一个让人筋疲力尽的投入。这种情况会最终导致测试人员的精力只能覆盖有限的几种用户场景,可能让某些重要的缺陷被漏测。

手工测试对于人的耐心细致是一个巨大的挑战,人在重复中容易遗漏,犯错。在截止日期的巨大压力下会走捷径,更不用说没有精力挖掘表象以外的缺陷了。

持续的自动化测试,保障了每次运行的一致性,降低了人为的回归错误。人就可以专注在观察产品究竟发生了什么。

二 自动化让人有精力做更有价值的事

自动化测试能对抗人的惰性,当单元测试和功能回归测试被持续构建运行,意味着测试人员可以有更多时间进行有趣的探索,研究系统内在的薄弱环节。

自动化不一定会挖掘出多少新问题,但一旦出现失败结果,能让测试人员快速锁定人工测试不太可能逮住的问题。这种愉悦感受是一种意外的欣喜。

三 增加开发和测试的信心

在信心的加持下,以往的测试人力投入策略被优化,人工检查的任务量大幅下降。

对于缺陷修补反思,以及新特性的用例补充,也增强了对设计质量和可测性的思考。开发人员养成了好习惯,修改代码前仔细思考要改变的行为,主动编写测试来验证它。最终培养了更优秀的编码人员和测试人员。

正确的自动化安全网,对于大规模敏捷团队的满意度至关重要。如果没有这个安全网,测试人员就会被当成兜底的安全网,压力被转移到测试人员头上。

自动化安全网对失败的快速反馈,让开发人员在记忆犹新的情况下极低成本解决问题。

四 自动化回归集就是最强大的文档

拥有一个匹配的自动化框架以及完整更新的回归套件,就能指导团队更好的捕获需求,并养成在迭代中关心测试方式改良的集体习惯,进而让需求可测性不再成为难题。

自动化测试库和代码库一起发展,团队也不用产生太多技术债。

更惊喜的是,测试实例就是讲述系统如何工作的“活文档”。因为它可清晰执行,出了问题不会带来过多的争吵,这比不常更新的静态需求文档要强大很多。

PART2 自动化实践的阻碍因素

一 开发人员的态度

很多传统公司,开发和测试不在一起工作,开发看不到测试的具体工作,也不关心。瀑布型研发模式,导致测试环节距离开发的工作更远,等到测试人员热火朝天的时候,开发可能进行下一个版本开发中了。即使是能熟练掌握单元测试的开发,也可能不会思考单元级别以外的验收质量。

如何改变开发人员对自动化测试的态度呢?

让他们动手测试是唯一方法。但是教练角色是需要的。开发团队,尤其是主管,要承诺测试目标,哪怕目标定低一点,愿意投入培训,并给予一线员工足够的鼓励。

二 降低测试自动化的学习曲线。

注意从设计很差的遗留代码上开始工作,难度会非常高,可以先从增量代码开始实践,找一个架构设计良好的模块来学习。当团队熟练掌握了一个测试框架,再进行旧代码的全面测试。

在初期,团队要评估合适的测试套件,得到实际的覆盖率。

对录制回放型工具要谨慎使用,UI级脚本不止有变化失效问题,还有知识难以传承导致的维护性问题。

敏捷项目中,虽然代码总是频繁变更,但是编写代码的目的很少改变,因此,按照应用的功能目的去组织测试脚本,就更容易跟上开发的节奏,而不是按测试代码的实现方式去组织。

度量开发进行自动化测试的收益,不要只看初期成本,还要看机会成本,即快速修复和项目后期修复的成本差距。

三 编程能力不足的恐慌

自动化测试是整个团队的事,团队中总有能够且愿意提供帮助的技术高手,即使是编程能力不高的同学也能做出贡献。

四 旧习惯

让没有持续自动化的团队开始实践,最常见理由就是:业务发布太紧了,新特性太重要了,没有时间实践自动化测试。还是用手工测试尽量完成所有事情吧,这样安全。

故步自封的态度,只会拖延技术债务,让形势逐步恶化。手工测试完成的内容也不能保障都是重要的,依然可能遗留导致重大经济事故的缺陷。

鼎叔能看到,当业务繁忙项目开始实践持续自动化后,测试人员的日常工作模式发生了变化,从被业务需求叠加的压力中,抽出更多心思放在补充稳定的拦截场景,而不是为各种可能的漏测事故进行焦虑式沟通。

我们理解基于团队的历史文化,工程师很难让业务测试自动化的优先级,高于新特性编码的任务,但是敏捷方法实践可以逐步克服这个障碍。未来公众号会给出更详细的分享专题。

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484206&idx=1&sn=363750ae0b28ddbe22aa1138f2046829&chksm=c24fb64cf5383f5aa0799f60ded2b91b7fddcbc880c61564bb4b91f780cfca5b68b9df60d354#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 5374
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线