【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

敏捷测试专家徐毅:怀疑论者的思维模式

  • 2013-09-16
  • 本文字数:4095 字

    阅读完需:约 13 分钟

测试的重要性和价值,已经毋庸置疑,然而,怎样才能借助于测试与质量为企业贡献价值呢?

敏捷、精益,移动、云计算,方方面面的变化都给测试与质量工作带来了极大的挑战,又该如何直面这些挑战呢?

这是今年 QCon 上海的大测大悟专题试图回答的问题。今天,我们邀请到本专题的出品人,敏捷测试专家徐毅,来分享一下他对于测试的一些观点,以及这个QCon 专题有哪些让大家有所收获的内容。

InfoQ:首先,请简单的介绍一下自己目前负责的工作,以及自己在测试领域做过哪些方面,关注过什么。

徐毅:我叫徐毅,现在在康仕诚公司担任资深敏捷顾问工作,提供跟敏捷开发、敏捷测试和敏捷转型相关的服务。

(注:关于我的测试历程,在图灵社区上我写过好几篇文章详细地描述过

刚开始工作时,做过一段时间的开发工作。05 年初在杭州的前诺基亚 3G 研发中心开始从事测试工作,负责某些功能模块(我们称之为 Feature)的测试,在我们的测试流程中,所负责模块的所有测试活动都要负责,从编写测试计划、设计测试用例、执行到检查结果和编写报告,包括所有的测试类型,都由同一名测试工程师负责,还要负责报告缺陷和推动开发人员修复缺陷;同期也加入了新成立的测试自动化组,是其中仅有的两名成员之一,这对我的测试哲学影响非常大,由于从一开始做测试就是结合着自动化,所以我也坚定地认为没有任何测试不可以被自动化,只取决于实现它需要投入多少以及大家愿意投入多少成本去实现它。随后开始负责一些更大型模块的测试、模块集的回归测试以及更大的领域(我们称之为 Domain)回归测试。

06 年 1 月我加入了我们的第一个 Scrum 试点项目,成为了最开始的 4 人团队(Grid)里的第一个也是唯一一个测试人员,开始以敏捷方式做测试。我们尝试抛弃了几乎所有现有流程,从零开始思考,到底有哪些流程和规范是需要的,然后再加进来。结合测试自动化、持续集成等各种实践的经验,我们制定了一套更敏捷的测试流程,作为新的整体研发流程的一部分。

同期我也一直在做测试自动化的工作,从编写脚本、开发维护 library 再到接手负责公司内部的一个模块化测试自动化框架(HitMan);之后作为测试自动化组成员,对 robotframework 进行评估并开始使用,作为第一批 4 名内部培训师之一负责培训和推广 robotframework 的使用;后来,产品线进行了 Scrum 大转型,所有的测试人员都必须要使用 robotframework 编写自动化的测试用例,这制造了带很多的麻烦,作为组织内第一批 2 名测试自动化教练之一,负责辅导 Scrum 团队内的测试人员学会使用 robotframework 工具以及做好测试自动化这件事,包括规划整体的测试自动化体系。

07 年中,我加入了另一个新产品开发担任其中一个团队(Thunder)的 Scrum Master,我们依然采用敏捷开发方式。一开始我还需要投入 50% 的工作量用来做具体的测试工作,但由于 Scrum Master 工作任务的零碎和不可预期,使得我难以保障工作任务按期完成,于是我开始辅导团队内的两名新手测试人员。我的目标是辅导他们编写质量上乘的自动化测试脚本,通过提升质量、降低维护成本抵回我所损失掉的 50% 工作量,个人目测 2 个月后就达到了这个目标。同时,基于前一个试点项目的成功经验,我们非常重视持续集成工作,并组建了一个虚拟的团队(可以看做是一个 SWAT 团队),由经验丰富的工程师组成,包括开发人员(秦之远,曾于 QCon 演讲过持续集成)、测试人员(也即是我)、直线经理等各种角色,以便随时响应修复失败的 build,捍卫持续集成最重要的纪律“保持 build 始终可用”,从确立 SCM 策略、编译问题、测试环境、测试脚本等各种问题都需要解决。

08 年底,我加入了公司内部名为“Flexible Company”的敏捷转型团队担任精益及敏捷顾问,负责支持全球范围内诺西(时为诺西)所有研发中心产品线团队的敏捷转型,敏捷测试的辅导也是我工作内容的一部分,包括以核心团队加实践社区的方式推动测试自动化体系的建设和稳固,以及在研发组织内建立敏捷测试的文化和体系。

11 年我去了上海惠普,在企业服务(Enterprise Service)部门担任资深敏捷顾问;12 年去了北京诺基亚手机,担任敏捷及精益教练;13 年回到上海,加入了 CCG 担任资深敏捷顾问。在这期间,我的工作内容都是辅助内部或外部客户,推动敏捷开发方式的普及、推动敏捷转型,或是推动敏捷测试的落地,等等。

InfoQ:您目前关注的重点是什么?

徐毅:具体一点的话,我关注如何让测试在敏捷开发方式下发挥更大的作用,以及如何让测试自动化和持续集成成为研发效率提升的基石。泛一点的话,我关注如何以各种方式提高测试工作的效率和效果,并对研发价值的整体提升做出贡献。我也很关注如何结合系统思考、学习型组织、精益创业等很多的优秀理念,把它们都运用到敏捷转型或测试提升等过程中去。

InfoQ:感觉在过去一年,自己接触到的、关注的领域发生了什么变化?

徐毅:感觉云、虚拟化、大数据等一些概念进入了更务实的阶段,而且在业内一些公司已经开始对测试工作产生了很多的正面影响。

作为一名自豪的前诺记人,惊闻微软将以 70 多亿美元收购诺基亚设备部门,我的心情非常的复杂。

InfoQ:您认为要让测试在敏捷开发方式下发挥更大的作用,是否必然会涉及到开发人员与测试人员角色的合并,以及自动化测试的完整覆盖?

徐毅:

【关于角色】

首先,敏捷开发方式要能够发挥作用,几乎所有牵涉到的角色都需要做出改变才行,不仅仅只是测试同仁。但这并不一定是通过“合并”的方式,更多的是“融合”。在此过程中,现有角色有可能消失,也有可能被赋予了新的内涵,也有可能演化出一些新的角色和职位。

其次,我们要区分“做事的人”和“做什么事”。在我们很多的讨论中,“测试”、“开发”这些词汇往往即被用来描述一个职位、一种角色,也被用来描述一件事(也即测试这种活动)。在传统方式中,测试这件事被绑定在了测试这个角色的身上,其中一大原因就是在大多数流程中,测试都被看做是在某个阶段可以集中完成的事务,这样的情况下,自然是专业分工一批人出来只做测试的效率和效果最佳。然而,在敏捷开发方式下,测试的颗粒度越来越小、频率越来越高,沿用传统方式根本就无法有效地开展测试工作,而传统意义上的“测试人员”在这种情况下也很难履行自己的职责。同样,频繁交付新功能的同时还必须确保不会损害已有功能,关键在于“回归测试”的效果和效率,不仅需要加强测试自动化以提升回归测试运行速度和效率,也需要扩大回归测试的覆盖面,从传统的功能测试、集成测试等,扩展到测试金字塔的每一层。而这些变化是不可能只靠头顶“测试人员”称号的工程师就能完成的,这就意味着掌握开发能力的工程师也需要参与测试活动中。他们需要做好自己所开发代码的单元测试、理解测试工作并提高代码可测性、支持测试自动化工作,甚至是向测试人员学习测试技能以改善其单元测试的效果。

取决于企业环境和行业的不同情况,以及敏捷开发方式的不同实现情况,角色变化的具体情况也会有所不同,无法一概而论。

【自动化测试的完整覆盖】

当富士康都开始大规模启用机器人的时候,我们还在讨论自动化测试的必要性或是覆盖率,其实是很搞笑的一件事情。

自动化的好处在于,当测试被自动化之后,就不再存在决定“这一轮测试执行还是不执行”的困扰了。当然,这需要做到高质量的测试自动化,而且是自働化。测试自动化可不只是写写脚本,工具的选择、整体规划都非常的重要。推荐大家看看业内第一本专门讲自动化的著作,Mark Fewster 和Dorothy Graham 的《 Software Test Automation 》,虽然年代久远,但仍然非常有价值。

然而,谈论“完整”,则又是一件很搞笑的事情。完整不完整,取决于分子(已自动化的测试)和分母(所有的测试)两个元素。对于测试这回事来说,我们都应该知道,测试是不可能穷尽的,那也就意味着,分母是接近于无穷大的一个数字。在这种情况下,想做到“自动化测试的完整覆盖”只能是痴人说梦。制定良好的测试策略,以此挑选、确定需要执行的测试,从而保障测试的效果;加强测试自动化,从而提高测试的效率。

“100% 测试自动化”并不是一个好的操作型定义,但它却能够逼迫我们去想办法尽可能地提高测试自动化率。而测试自动化率则直接影响到我们在敏捷开发方式下的交付频率和质量。

InfoQ:不知道您对于“其实我们根本不需要测试人员,开发者应该自己做测试”这个观点是怎么看的?

徐毅:这是一个非常有争议也常常被提起的话题。作为测试人,首先需要研究的就是命题本身,也即这个观点本身。我们重新来诠释这个观点的话,它的潜台词就是:“测试这点事,我们不需要专门的测试人员来做,我们开发人员完全可以胜任。” 再细细剖析,那就不得不提出一些质疑了:

  • 测试这点事到底包括哪些事,冰山之下是否还有暗礁?
  • 完全可以胜任,意思是可以“执行”这些活儿,还是说能够做得一样好,效果一样?
  • 有能力做到,是否意味着一定会去做这些事呢?如果不是,那这些活儿谁来干呢?
  • 即便开发人员能够胜任这些工作,他们需要为此投入多少时间呢?10%?30%?50%?80%?这个时候,还称呼他们“开发人员”是否合适?

所有这些争执的缘起,只因为测试队伍里有不称职、不上进的同仁,而开发队伍里也有一样不称职、不上进的同仁,以他们为标准的话,自然是不需要专职人员,其他角色均可以取而代之。一名用户文档编写人员,如果也具备了高超的开发技能,我们是否可以说“其实我们根本不需要开发人员,用户文档编写人员就可以自己做开发”呢?基于微观事实做出宏观论断,没有意义,也无助于改善现状。

在我看来,开发、测试的最大区别在于思维模式的不同。开发的思维模式更像是创建型,从 A 到 B,想方设法也要找到一条路,不管有多少可能性,必须找出一个来;而测试的思维模式更像是怀疑论者,这条路真的能到 B 吗?路标清晰吗?这是 A 到 B 的唯一一条路吗?万般可能性,最好统统试一遍。

推荐大家阅读 Elisabeth Hendrickson 所著的《 Explore It 》。

InfoQ:方便举一个例子介绍虚拟化对测试工作产生的影响么?

徐毅:在测试工作中,一个比较常见的瓶颈就是有限的测试环境资源,利用虚拟化技术,辅以测试的分布式并发执行,可以缓解这一方面的问题。

而且虚拟化也有助于解决测试环境标准化和 bug 现场重现等一些问题。

2013-09-16 00:401554

评论

发布
暂无评论
发现更多内容

Java最新高频大厂面试集锦(附答案),看完老板哭着让我留下来

Java 程序员 后端

Java程序员裸辞两个月,面试阿里、美团,mysql视频教程百度云

Java 程序员 后端

Java进阶之梯,成长路线与学习资料,助力突破中间件领域

Java 程序员 后端

Java虚拟机学习集锦是我攒来的,但为你能过面试的心是真的!

Java 程序员 后端

Java程序员:终于,在一个艰难而又轻松的工作日之后,java开发工程师常见面试题

Java 程序员 后端

Java笔记 IO —— 序列化和反序列化,面试大厂应该注意哪些问题

Java 程序员 后端

Java线程状态以及 sheep(),开发这么久这些问题都不会

Java 程序员 后端

Java注解(1),headfirstjavapdf百度云

Java 程序员 后端

Java的新未来:逐渐“Kotlin化,java接口菜鸟教程

Java 程序员 后端

Java程序员拿80W年薪很难吗?这套阿里P7的进阶路线让我惭愧了

Java 程序员 后端

java注解解析,10天拿到字节跳动Java岗位offer

Java 程序员 后端

Java的四大面向对象编程概念,程序员必须要了解的知识点

Java 程序员 后端

Java线程池相关知识点总结,mybatis基础面试题

Java 程序员 后端

JAVA线程池源码之深入状态值分析| Java Debug 笔记,java面试题库百度云链接

Java 程序员 后端

Java注解,mysql教程入门到精通

Java 程序员 后端

Java流程控制语句-分支结构(选择结构),java技术专家面试题

Java 程序员 后端

Java状态模式(State),马哥linux2020全套视频下载

Java 程序员 后端

java程序员跳槽难吗?掌握这些经验,轻松入职阿里,rabbitmq的消息持久化原理

Java 程序员 后端

java虚拟机,狂神mybatis笔记

Java 程序员 后端

Java虚拟机:Java内存区域及对象,java反射面试

Java 程序员 后端

JAVA设计模式类第一博主,用这份文档覆盖GOF研磨这23种设计模式

Java 程序员 后端

Java模板工具类实现解析简单的表达式,kafka实战项目

Java 程序员 后端

Java毕设项目-校园失物招领管理系统,HR的话扎心了

Java 程序员 后端

Java程序员经典面试题集大全 (二),最全SpringBoot学习教程

Java 程序员 后端

Java程序员被逼迫,挣着卖白菜的钱,操着卖白粉的心,java语言入门自学书

Java 程序员 后端

Java类与类之间的继承关系,java算法面试代写

Java 程序员 后端

Java框架总结,mysql教程视频

Java 程序员 后端

Java注解-一文就懂,mysql注入攻击原理

Java 程序员 后端

Java的Io模型你了解多少?RPC的通信Netty-Netty的底层是Nio-

Java 程序员 后端

Java程序员黄金年龄25-28岁,我们30+的人该去哪儿,linux资料

Java 程序员 后端

Java虚拟机 —— 类的加载机制,linux操作系统实用教程第二版课后答案

Java 程序员 后端

敏捷测试专家徐毅:怀疑论者的思维模式_QCon_sai_InfoQ精选文章