如何不让“测试”成为敏捷的绊脚石?

最近一次,也就在上个月做的一次在线调查显示,大约60%的公司/团队已开始进行敏捷测试,而之前的调查显示则只有51.2%,不管数据是否存在一些误差,但历史的车轮总是滚滚向前,敏捷开发模式会不断扩展,渗透到研发的每一个角落,甚至向运维渗透,由此产生DevOps。

 但是,从我写 第一篇“敏捷测试”文章(2010年发表在CSDN《程序员》杂志上的“敏捷测试的方法和实践”),过去八年了,感觉国内软件敏捷测试进步不大,许多问题依旧存在,不少人的困惑也没有消失,甚至不断增长。从敏捷模式落地看,开发遇到的挑战的确比测试要小。虽然敏捷提倡TDD,但开发却很少去实施TDD,甚至单元测试也没多大改善,根据 国内软件测试现状调查分析报告 调查结果显示 要求做到80%以上覆盖率的企业不到20%,多数企业根本没有要求。单元测试本来是敏捷测试的基础,而由于任务重、开发强势,单元测试而被忽视。持续集成,更多依赖于特定的配置管理团队和Jinkins这样的工具实现,开发只是在check in时间上有一个配合。许多持续集成,也只是实现了持续构建,而缺乏良好的自动验证。所以,在敏捷开发中,开发不容易成为瓶颈,而测试则容易成为瓶颈,这主要有以下几个原因:

  • 开发的单元测试做得不好、做得很少
  • 回归测试的工作量不断增大,而迭代周期是不变的
  • “测试:开发”的配比很低,测试工作其实不低,但人太少。(可以参照谷歌,那么开发人员就要做足够的测试,但又不是;也可以融合,但又不敢融合)
  • 测试自动化没那么容易实现,不仅因为测试人员少、能力弱,而且产品耦合性强、可测试性低
  • 不恰当的测试策略、测试方式或测试方法等

无论是去年的调查还是今年的调查,主要的问题依旧表现在这些方面

排在第一的是“需求I问题”。在各种场合,人们也都抱怨“需求不稳定、需求变化过于频繁”。这里肯定有大部分研发人员对敏捷宣言中“拥抱变化胜于遵循计划”的误解。敏捷宣言中“拥抱变化”绝不是拥抱人为造成的需求变化,如因为在需求分析上投入不够、评审不到位、需求表示方法问题等造成的需求变更。拥抱这样的变化,对企业的影响只能是负面的,只能增加研发返工的概率,最终增加企业成本。我相信敏捷宣言中“拥抱变化”,是拥抱“用户或业务真实需求的变化”。我们能够及时交付用户所需的新特性,是为了适应用户或业务真实需求的变化,而不是为了纠错研发人员自己的疏忽、粗心大意或不认真。

在许多人眼中,敏捷只是代表快,快速迭代,往往忽视敏捷最核心的理念是“尽早向客户交付价值”。交付价值,没有价值的东西不交付。敏捷不代表交付功能特性越快越好,而是交付有价值的功能特性越快越好。

没有良好的单元测试、没有良好的设计甚至没有良好的需求,这些问题的暴露可能就落在测试上、产品线上,更何况我们还有“代码重构”、“灰度发布”、产品线上troubleshooting等大招,哈哈。有些开发甚至喜欢troubleshooting,没有troubleshooting,怎能体现他们“强大的实力”?出现问题,会打“测试”几大板,又体现开发的威武,何乐而不为?

如果原来不重视需求、设计和代码的质量,实施敏捷以后,可能会更加肆无忌惮地忽视需求的分析和评审、设计和代码的评审、单元测试等等,那么情况只能更糟糕。研发这过程会流失了很多,包括客户和金钱。

实际上,没有人去计算因需求、设计、代码的问题而返工造成的成本——劣质成本(COPQ)。只要大家足够忙,不断有新的特性交付(哪怕是错误的特性),似乎一切都OK。

测试人员能力弱是另一个大问题,毕竟在国内或多或少存在这样一种错误理念——干不了开发就干测试。有不少人,把门槛相对低的测试作为进入高薪IT行业的一个入口。许多人干测试,并不是热爱测试,而只是找到一个相对体面的工作。正如在 国内软件测试现状调查分析报告 点评道:人的问题可能是最根本的问题,敏捷文化、价值观也是由人来承载,自动化测试也是由人来实施,方法、流程等改进也都是由人来驱动。人的素质和能力达不到,搞敏捷就会搞得很辛苦,加班比以前更多了,可能质量和效率并没有提高。

国人喜欢关注具体的技术和工具,而不关注“文化”或思维方式,这对进行敏捷开发也是很危险的。现在大多数开展敏捷开发,都是采用Scrum模型,而Scrum的确没有教你如何做软件开发,因为Scrum模式台简单、通用了,几乎可以应用到任何一个行业或领域,而不像XP,其中12项实践中大部分实践只适合软件开发。BDD看似简单,但也解决了软件工程中最难的“需求问题”。

人们的思维方式也会在变,今天朋友圈就被“陆奇为什么值钱?因为他的原则值钱”这篇文章刷屏。人们也更关注做事的原则。做软件测试,大家或多或少也会坚持一些原则,有的测试人员是潜意识的,多数测试人员是有意识的,更优秀的测试人员是会主动运用测试原则制定测试策略。测试的原则代表着测试思维。

回到敏捷开发中,测试如何突破瓶颈?

之前给华为做的讲座是谈到这是个方面:

今天会多谈一些,但有些更深的内容(一时半会说不清的)则忽略。

无论采用瀑布模型、敏捷模式,“测试计划、测试分析与设计”没有明显的差异,这些能力都是测试的核心能力,都是必须建设的,虽然在敏捷开发中,尽量简化测试计划——一页纸测试计划。但本质上没有改变,写测试计划就是根据上下文来确定,不是为了计划书而写,而是真正能指导测试的设计与执行,就可以。但有些能力是不一样的,例如自动化测试能力,虽然在瀑布模型也很重要,只是传统开发周期长、需求稳定、清晰,测试配比相对也比较高,没有自动化测试也能支撑测试的正常运行,但在敏捷测试中,没有自动化测试就可能是寸步难行,久而久之,一定敏捷不起来。

概括起来,让测试敏捷化,需要从下面七大方面做一些转变、改进,甚至是彻底的文化革新或技术突破。

  1. 测试思维过去,测试更关注发现Bug,更突出测试对质量负责。要使测试能敏捷起来,必须强调质量是构建起来的、团队对质量负责,加强需求/设计评审、加强单元测试。

2. 测试周期

尽最大努力缩短软件测试周期,适应持续交付,确保测试不成为交付的瓶颈,如:

  • 需求即测试(如BDD、需求实例化等),减少中间转换环节,与开发、产品/业务一开始就达成共识;
  • 已知测试,不写测试用例,直接写测试脚本;未知部分,先探索式测试,等到如何测试,就直接转化为自动化测试。参考:软件测试的一个新公式引起的思考
  • 每个测试(test是,相当于一个test case)的时间低于60秒,这就需要进行分层测试,加强API测试。
  • 测试脚本相对独立,可以拆分,并行执行测试,以缩短测试周期

3. 自动化测试

从单个工具(如Selenium、Appium)执行测试开始,从一般的脚本扩展到数据驱动、业务封装或关键字驱动脚本等,最终构建完整的自动化测试框架,覆盖全生命周期的测试和各个层次的测试,并体现高度的自动化,从需求可执行、测试建模、测试数据生成、测试设计到测试执行、报告自动生成。

4. 测试环境

传统的测试环境强调独立性、稳定性。

敏捷中也要有独立的测试环境,也需要确保测试环境的稳定性,但更强调采用Docker新技术和虚拟机技术,实现更快速的自动部署,并和整个开发、质量管理、运维等系统的集成,形成从开发到运维端到端(扩展为DevOps)的测试环境。在这样的环境中,不仅能够完成测试的计划、设计和执行,而且可以实时监控系统运行行为和日志分析,实现深度的用户行为分析、及时收集用户反馈,及时改进测试的设计,并帮助开发预防缺陷。

5. 度量

越快越要透明,越需要度量,否则就会混乱,欲速则不达。况且,软件及其开发,就是数字化工作,度量是相对容易的。虽然全面的度量指标体系不能一步到位,但可以逐步丰富、改进或优化。一直反对像CMMI、TMMI将度量、量化管理放在Level 4,缺陷预防放在Level 5,而且隔离过程域(参考:解密TMMi、CMMI)。每个公司只要存在就有了过程定义,虽然不完善,过程需要改进,其它关键领域(测试计划、非功能性测试、相互评审)都应该先动起来,度量对测试一定是一个很好的支持,数据驱动质量管理对软件研发就是天生的,很早就可以动起来,可以帮助测试过程改进。

从缺陷度量、测试用例执行来基本的测试度量,可以扩展到全面的质量度量,构建完整的quality dashboard,而且现在也有类似SonarQube这样的工具或平台支持。

6. 测试与开发融合

质量中心作为管理部门,需要覆盖研发、运维、市场销售等各个部门。其成为一个独立部门是顺势而为。但测试是属于研发的一部分,没必要独立,需要和开发融合。之前,测试人常常将微软公司作为标杆,说明测试如何得到重视、测试和开发的比例如何之高,今天这个标杆已经不存在了,因为四年前(2014年),微软就逐渐去掉专职测试人员岗位,都统一成为“软件工程师(software engineer)”。今天看来,微软转型也是成功的。

在敏捷开发转型中,我们也应该消除测试部门,到消除专职的测试人员,从而实现开发与测试的彻底融合。在这过程中,可以设立“Test Owner”角色,负责项目的测试计划(含测试策略制定)、测试工作的质量,指导其他团队成员做好测试的设计与执行,帮助团队建立良好的测试能力。如果在LeSS或SAFe中,可以设立Test Owner of Test Owner。

7. 组织的支撑

测试敏捷化,当然也离不开管理层的大力支持,包括倡导先进的敏捷思想与文化、组织结构的改变、为开发人员提高测试培训等,预算、人员等方面的支持,思想文化层面的支持不需要多大成本、甚至不需要成本,只是领导要有这样强有力的意识。而组织结构的改变是局部的,风险是有限的,企业需要承担一定的风险,不变则一定等死,变才有可能新生。

具体实践,统一资源,在公司层次建立自动化测试框架、测试平台或测试云服务,同时建立测试能效团队,让一部分测试工程师加入进来,为公司提供测试所需的、较通用的测试工具。

参考:

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我
  • 上海市嘉定区曹安公路4800号同济大学软件学院
  • kerryzhu@vip.163.com