分类目录归档:数字化

BQConf演讲:软件测试人员该何去何从?

本文根据11月23日第39届BQConf北京的演讲《软件测试人员该何去何从》整理,为了便于阅读,稍作修改并增加了不同级别的标题。

三个故事

01. 面试中的他

两年前的一个下午,天气有些雾霾,在三楼光线不是特别明亮的会议室里,我和另外一位工作年限跟我差不多的同事面试一位有着10年经验的候选人。

对于跟一位工作十年的候选人见面,我和同事都挺期待,提前沟通好,做好了充分的面试准备。走进会议室,看到一位身材高大、略显疲惫的男士,没有我想象的那种阅历丰富、干练自信的样子。

简单寒暄之后,我们正式进入面试流程。他介绍了自己的工作经历,详细描述了自己这些年所从事的工作的点滴,听下来并没有太多的亮点。出于对候选人负责,我们想尽力去挖掘他的一些加分项,但是,很难,最终无果…

他来自某大公司,多年一直处于一个部门,从事几乎没什么变化的手动测试工作,工作强度不大,对技能要求也不是很高,他在那里做的得心应手。不料,公司业务发展调整,需要部分裁员,他不得不另谋出路。

02. 屏幕那头的她

一年前,我写了一篇文章《微服务测试的思考与实践》。有位朋友看了我的文章,给我发来微信,她觉得我的文章内容对她很有启发,就文章内容跟我进行了咨询和讨论。

她对内容很认可,但是执行起来她觉得没那么容易。我俩聊着聊着,她开始跟我讲她现在的困境:她有简单的编码技能,但是对于更多底层技术、架构方面的知识比较缺乏,在项目团队想推进一些技术变革重重受阻。她做QA也有好些年了,这两年老觉得行业技术更新太快,自己的技术热情和时间有限。而随着工作年限的增加,别人(团队)对她的要求也就更高。

她是一位妈妈,一方面需要照顾家庭和孩子,一方面感觉到工作技能提升的压力,她感觉自己遇到了职业瓶颈。

03. 放弃测试的他们

两个月前,两位好友一起吃晚饭。很久没有相聚,自然是有很多话题聊的。

他们两个都是曾经做测试的,现在分别转做了开发和管理。席间我们聊到了这个话题,身边做QA或者测试的朋友转角色的还不少。我被问到是否考虑转角色的问题,同时,我也听到一个说法:大家都从QA转别的,毕竟QA的地位还是要低一些。

故事讲完了,大家有何感想?

我们来看一下故事里提到的测试人员面临的问题有哪些:

  • 多年重复手动测试,只是关注自己手头的事情,大公司的部门壁垒,跟别的角色、别的团队较少沟通,相对比较封闭。但这些似乎并不影响做好手头的测试工作,觉得自己是“能力够用”的,在这个舒适区待着很爽,自然没有学习提高的动力。
  • 长此以往,应对变化的能力会越来越弱,随着年龄的增长,本应该同样增长的技能却没有相应的增长,感受到外界的压力增加;如果还有身份的变化,成为上有老下有小的夹层,来自家庭的压力导致用于技能提升的精力减少,更加难以提高。
  • 得不到技能的提高,在团队的影响力减小,话语权降低,不被重视,甚至自己也在怀疑所做工作的价值…于是,只好选择换一个角色…

当然啦,有些朋友是真的觉得测试工作不适合自己,转做别的更适合的工作,这些朋友除外。比如跟我吃饭的那两位好友,他们现在都干的很好!

那么,软件测试人员真的有这么悲惨吗?
World Quality Report

由Capgemini、Micro Focus和Sogeti联合组织问卷调查,每年出具一份《World Quality Report》(全球质量报告),今年已经是第10期了。报告列出了大家关注的质量趋势,也会给出一些推荐的做法。报告内容非常多,每期都是70页左右的英文版文档,去年和今年的报告我都有写文章解读,大家感兴趣的可以参考我博客网站上的文章《数字化时代的软件测试》和《关于质量,大家都在关注什么》获取更多细节。

下面来看今年的这份质量报告给我们带来了什么。

我们知道,软件系统首要的是满足功能需求,所以功能是最为核心的内容,但已经不能止步于此,在功能的外层还有更高的质量目标。大家请看图,在功能需求外还有四个方面,分别是:

  • 安全: 信息化时代安全的重要性不言而喻,不仅指应用程序本身的安全、对用户隐私的保护,也包括软件开发过程的安全性和软件资产的安全管理。
  • 速度:互联网时代瞬息万变,都在追求速度上的质量。同样,速度不仅指应用程序本身的性能,也包括交付的速度,从idea到成品交付到用户手里越快越好,抢占先机!
  • 便利性:应用程序能给用户生活提供多大的便利程度,比如说打开一个外卖软件,可以多短的时间找到需要的餐馆,是用户非常看重的一个质量指标。
  • 体验:第四个是用户使用系统的综合体验好坏,易用性、页面的布局和配色等都会影响到用户是否愿意给应用买单。
最高质量目标:终端用户满意度

这四条围绕功能而高于功能的就是终端用户的满意度,是今年质量报告反应出来的大家的最高质量目标!

质量备受关注,对质量的要求越来越高,软件测试或QA工作的重要性不言而喻,我们大家所做的工作毫无疑问是非常有价值的!

同时,随着质量要求的提高,软件测试也不再是发现缺陷那么简单,对我们测试人员的要求也有很大的变化。

为了走出前面故事中的那些困境,我们需要行动起来。

行动起来

01. 学习

面临的问题

显然,最关键的行动一定是学习!说到学习,我们有必要先来看一下大家学习可能面临的问题:

  • 技术日新月异,太多的东西要学,我该从何学起呢?

的确是这样,信息化时代,学习渠道、学习的内容都是无穷的,要学习先要甄别哪一个是值得学的,无疑给学习提高了门槛,这也使得有部分人无从下手,就干脆不学了…

  • 不知道从哪学起,那么我们就先学一个东西再说,学了总比没学好!

这种做法在过去知识比较匮乏的时代,是可取的,学了一定会比没学要好,说不定哪天就能用的上了。但是,现在处在信息化的时代,有些知识是可以不需要花太多精力去学,可以从互联网简单搜索获得的。毕竟精力是有限的,如果花时间学习了这种本可以轻松得来的知识,是很大的浪费。

  • 目的性不强,学到了零散的知识,也很难真正派上用场,最后这个知识还是会被遗忘。

比如说,现在Python很热,小学生都在学Python编程了,觉得我们要还不会就落伍了。可是呢,学了半天,也没有实际用上,过一段时间发现也记不得多少了…这样进行几次之后,会严重影响学习的积极性,发现学了也没用,好像还不如不学。久而久之,就放弃学习了…

学习这么麻烦,我们该怎么学习呢?

学习的过程

我们先来了解一下学习的过程。学习面对的是海量的知识,我们需要从中挑选自己需要的部分,进行加工和提炼,变成自己掌握的知识。到这是不是就结束了呢?并没有。还有最后非常关键的一步,那就是把学到的知识应用到不同的领域,或者总结分享出来供他人学习和使用。

学习的过程

也就是一个完整的学习过程应该包括三个部分,分别是:知识输入、加工提炼、知识输出。缺失其中任何一步,都不是正确的学习。

讲到这里,我想问今天到场的各位朋友一个问题:平常大家都会读很多书,请问大家怎么定义读完了某本书?

答1:我会根据书上介绍的做Demo在团队演示。

答2:我会总结书里的内容在团队分享。

前面两位朋友回答的都非常棒!我想介绍我的一位朋友的做法,他对读完一本书的定义是必须有输出,输出可能但不限于下列的一项或多项:

  • 写读书笔记分享;
  • 提炼书中观点,结合自己的经验总结成博客文章发出;
  • 运用书中理论到工作实践中,在团队以工作坊或小型演讲方式分享;
  • 或者以演讲的方式到大会上分享给更多人。

就是在这样不断反复学习、总结、分享的经历之后,他成为了某技术领域的专家!

学习的正确姿势

了解了学习过程,我们还需要了解学习的正确姿势,以确保学习是真正有效的。关于学习的正确姿势,我认为有两个比较关键的。

首先,根据前面讲的学习过程,最终是要把学到的知识应用起来的。我们可以先搞清楚要把学到的知识应用到哪里,也就是我们学习的目标,搞清楚这个目标,然后利用目标倒逼输入,再进行学习的正向过程,也就是以终为始的做法。

比如:目前工作的项目上需要某项技术,我们有针对性的去学习这一门技术,这样的效果会比较好,能够达到事半功倍的效果。

又或者,目前工作中暂时用不上,但是自己很感兴趣的技术,可以作为学习目标,深入学习和研究,最终的输出可以是集结成文,或者演讲的方式分享出来。这样,不仅可以让他人获益,更重要的是对知识总结提炼的过程,加深了自己对知识的掌握,最获益的还是自己。

目标驱动、以终为始的学习

这就是我要说的第一个正确姿势:目标驱动,以终为始

这里,我们要搞清楚三个问题,也就是

  • Why – 为什么要学?输出是什么?
  • What – 要学什么内容?输入是什么?
  • How – 如何学?学习的方式,对于不同的内容需要采用不同的学习方式。

第二个学习的正确姿势是持续学习。这一点,其实没有太多可讲的,知识在发生着日新月异的变化,现在是特别需要活到老学到老的时代,不然很容易落伍,跟不上变化的步伐。

可能有朋友会说,我在目前工作中的技能已经完全够用了,我也没有很明确感兴趣的方向,该如何提升自己呢?

接下来,我们来看如何确定学习目标的问题。

学习的方向指导

对于目标不是很明确的朋友,不太知道如何从海量知识选择自己需要学习的内容,可以多关注一些趋势性的内容,以此作为自己学习方向的指导。

比如,前面我们提到的全球质量报告(World Quality Report)就是一份很好的趋势方面的内容。

质量报告里提到大家关注的质量趋势集中在五个方面:AI和测试、敏捷和DevOps、测试自动化、环境和数据,以及质量保障方面的成本投入问题,报告分别列出了这几个方面的现状以及未来几年的发展趋势。

同时,报告还给出了一些推荐的应对策略。我们拿其中的质量工程技能方面的策略来详细介绍一下,包括以下几个方面的技能:

质量工程技能策略建议
  • P0 – 敏捷测试专家,包括必备的自动化技能和领域测试技能。敏捷和DevOps的越来越普及,使得对敏捷测试专家的需求成为最高优先级的。一方面,自动化测试是敏捷的基础,要求敏捷测试人员必备自动化技能;另一方面,敏捷测试提倡测试左移,测试人员需要在需求分析阶段开始介入,对领域知识和业务理解能力有相当的要求。
  • P1 – 测试开发技能,处于P1的优先级,要求必备高级自动化、白盒测试、开发技能和平台构建能力,同时,对于AI方面的基础算法应用处理和自然语言处理技能是个加分项。
  • P2 – 接下来的是专项技能集,包括安全、性能等非功能测试、测试环境和数据的管理技能等。前面提到过安全、性能的迫切需求程度,同时报告也指出测试环境和数据的管理水平低下,导致这些专项技能的培养的优先级还是很高的。
  • P3 – 最后一个是高级QA专家,主要是AI架构技能,要求能够构建执行重复、智能任务的“智能测试资产”。鉴于目前AI技术的运用水平,对于这方面技能的培养可以稍缓,但的确是未来的一个发展方向。

下面再给大家推荐一个非常值得关注的技术趋势类读物,那就是ThoughtWorks的技术雷达。ThoughtWorks TAB(ThoughtWorks技术咨询委员会)根据我们在多个行业中的实践案例,每年为技术者产出两期技术雷达,对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。

关于技术雷达,也有朋友说上面跟测试相关的条目越来越少,对测试人员的参考价值不大。我们来一起看一下今年上半年发布的第20期技术雷达。

技术雷达V.20与测试人员关系密切的条目

技术雷达是按照技术、平台、工具、语言&框架四个维度,根据每个维度技术条目的成熟度分成暂缓、评估、实验、采纳四个环。乍一看,带测试字眼的条目较少,但这不代表跟测试相关的内容少。我尝试按如图所示的思维导图的方式做了一个总结,摘出测试人员需要关注的几个方面,并列出对应的技术条目。大的方面有DevOps&基础设施、微服务、自动化测试、线上监控与分析、安全、数据分析与机器学习、区块链等,对于每一块我们都可以相应的思考测试人员需要关注的点有哪些,这里就不详细讲了,更多的细节大家可以参考我的博客文章《软件测试人员的挑战与机遇》。

除此之外,还可以多关注一些技术社区、技术大会、技术类公众号,了解别人都在做什么、有什么新的技术等。相信大家也会有不少这方面的关注,欢迎一起来分享。

02. 沟通

学习是提升自身能力的途径,要想职业生涯更加顺畅,还有很关键的一个行动是需要增加跟他人的沟通,不可以独自处于封闭的状态下闷头学习。

首先,项目团队内跟不同的角色的沟通

我们一直在讲团队为质量负责,但是团队不同的角色对质量的理解可能不够透彻、对质量关注的意识也会不太够,作为团队的QA,是需要承担起质量协调者的角色的,需要把自身对质量的理解、当前项目产品的质量状态及时的跟团队反馈,需要跟不同角色有足够的沟通,让团队不同的角色能够更好的一起为质量负责。

当下流行的全流程测试,更是强调测试人员在各个环节的参与,跟不同角色的合作,比如说需求分析阶段需要跟业务分析人员合作,自动化测试需要跟开发人员合作,在生产环境下的QA又需要跟Ops的人员合作等。

在跟不同角色的合作过程中,不仅可以从对方角色那里学习到自身欠缺的技能,以丰富自身能力;同时,也可以让跟你合作的角色从你身上学习到测试考虑的角度,更好的做好质量的每一步。这是一个双赢的过程,1+1>2。另外,合作多了,大家也走得更近,工作更好开展,自然在团队的影响力就会增加,地位感也随之增加了。

团队内跨角色沟通

其次,更大范围的沟通

项目团队的充分沟通,有利于项目工作的顺利开展,但是,团队还是太小,需要扩大到更大范围。比如说,多参与技术社区、技术大会、技术讨论微信群等。相信今天来到现场的朋友们都是体会到这个方面的优势的,都非常积极的参会。

这里,我们要注意一点,如果只是看或者听别人分享的话,参与感是不太够的,效果不会太好。要多发表自己的看法,或者抛出自己的疑问,多跟人沟通,不是单向的吸收。除了一对一沟通,可以参与群体的讨论,或者对一些技术文章、所读书籍发表评论、读后感,还可以通过写文章、演讲的方式分享自己的经验所得。

请记住,有输出才会有收获。这个非常关键!

03. 突破

刚接触测试的从业人员,可能非常关键的一项技能就是要能尽可能的发现bug,于是我们有着很大的一个优势就是比较容易发现很多细节上的问题。这也同样带来一个问题,那就是有的测试人员过度关注细节,导致工作好几年还是容易抠细节,看不到大局。因此,我们的第三个行动是需要跳出来,做到突破,要有破局思维!

突破

首先,要培养系统思考能力。世间万事万物都是有联系的,构成众多大小不一的系统。

小的系统比如目前正在做的产品,当你发现某个功能有bug的时候,它真实的问题可能出在另一个你想象不到的模块,这个时候如果只是停留在你发现问题的模块,可能就浪费很多时间也难以定位问题;或者你发现一个bug,觉得它很严重需要紧急修复,但是当你结合市场情形、业务发布优先级、对终端用户的真实影响、修复所需成本以及开发人员手头其他工作的优先级综合来看,最后可能发现那个bug的优先级低了很多…

这是系统思考的两个简单的例子,由于系统思考不是我今天要讲的重点,在此就不多讲了。大家感兴趣的可以找相关资料,运用前面所介绍的学习方法去获取相关知识。

其次,需要扩大视野。前面讲到的关注技术趋势、参加技术讨论等都是扩大视野的途径。通过吸收这些信息,视野变大了,个人看问题的角度就会变的不一样,也就更容易去发现问题或者提出建设性的解决方案。

最后,遇到问题时,要运用系统思考的能力,跳出单一的小系统,利用曾经吸收到的各类有价值的信息,逐步建立自己的大局观

这几点,我认为都是测试人员非常需要培养的能力,也是帮助我们拓宽职业之路的有力助手。

前面讲到这么多,有些是通用的适合所有人,但是,我们还是需要结合自身特点去选择适合自己发展的方向和提升的方法,要结合自己的兴趣特长、性格特征来选择。如果没有跟自己兴趣特点匹配的也不用太过担心,相信兴趣特点也是可以培养的。我想送大家两句话:

选自己所爱,爱自己所选!

坚持就是胜利!

回顾与总结

今天通过三个我亲身经历的故事,我们看到了测试人员可能面临的问题。同时,给大家分享了我们可以采取的三个行动。最后总结一下,希望大家能够记住下面几个关键词:

  • 以终为始,持续学习
  • 沟通交流,让知识翻倍
  • 勇于突破,系统思考
  • 选自己所爱,爱自己所选

今天分享的这些是我在学习、摸索中的一些总结,我不是什么成功人士,所以这也只是抛砖引玉,希望大家更多的来一起分享和讨论,愿我们各位测试同仁们都有一个好的职业发展的明天!

RPA工具初体验

引子

一年前,在一次客户(老外)的演讲中,晕晕乎乎的在一大段英文中听到了RPA这个词,当时大概查了一下,了解到RPA是机器人流程自动化(Robotic Process Automation)的简称,跟自动化有些关系,但是当时也没搞太明白。

半年前,听说客户的IT部门开始培训大家用RPA工具UiPath来做自动化测试,但是遇到了一些麻烦,问我们这边是否有相关经验。还真不好意思,没有接触过,于是决定研究一下RPA到底是个什么玩意。

RPA初印象

首先看到的是埃森哲的《Getting Robots Right》文章,介绍了RPA的常见误区、案例分享,以及RPA的关键成功因素等,都是高大上的介绍,对于我这个没有接触过的人来讲还是有些云里雾里,只是对RPA有了大概的认识。

什么是RPA

文章提到RPA是使用软件来完成重复的、结构化的、基于规则的任务,从而大规模地自动化业务流程,最终实现企业级智能自动化,它是基于办公室的等效生产线机器人,基础技术是机器学习和人工智能。

简而言之,RPA就是用机器人(软件)来取代人完成工作任务。

文章还介绍了RPA可以做的事情,有处理事务、操纵数据、触发响应,以及与其他数字系统通信。其实就是像人工作那样操作不同的系统,处理不同的任务。

理想的可以用RPA工具来操作的应用程序可以在财务、人力资源、采购、供应链管理、客户服务/经验和数百个行业特定业务流程(例如保险索赔处理)中找到。

RPA用在哪里

到此为止,感觉还是很抽象,了解到RPA主要是用来自动化业务流程的,但是不清楚RPA具体是什么样的。

因此,还是先体验一下RPA工具吧。

RPA工具初体验

下载了目前市场占比最大的工具UiPath试用版,尝试使用它提供的录制回放功能录制了一个简单的步骤,的确可以工作,但发现对于复杂的、有条件跳转的还不能这么简单的实现。

通过研究入门手册,琢磨着编写了几个程序实例:一个是猜数字游戏,有两个版本;另一个是从网站查询指定城市的实时天气。它们长这样:

UiPath示例

左边的游戏是序列(sequence)形式,右边两个是流程图(Flow chart),跟平时画的流程图非常的类似,很直观可读。好像有点意思!

这是怎么做到的呢?麻烦吗?

UIPath工具提供一个图形化的编程界面UIPath Studio,由三个主要部分组成,Activities(默认在左边)、Properties(默认在右边)、中间是编辑和展示上图中那样的序列或者流程图的地方。

Activities里有各种活动的控件,比如:Input Dialog、Write Line等输入输出控件,以及If、While/Do While等条件/循环判断控件。将活动控件拖拽到中间编辑区域,设置跟其他已有控件的关系。FlowChart里可以通过箭头连接不同控件来设置其相应关系,而Sequence里则是按照控件摆放的上下顺序为先后顺序。

然后,选中编辑区域的控件,可以在右侧的Properties里设置对应的控件属性,比如:猜数字游戏,判断输入的数字跟实际数字的大小以确定弹出不同的消息内容,这些都可以在Properties里对应的设置。

同时,还支持设置相应的变量,比如猜数字游戏中的实际数字和输入数字都可以用变量代替,方便多次使用做比较。

因此,在UiPath里通过拖拽和相应的属性设置,全部在图形化界面上完成,就可以实现一个程序的编制,并不需要有编码工作,对编程技能没有什么要求。对于普通的业务工作人员来说,也是非常简单的。

UiPath Studio

这个简单实现业务流程自动化的工具似乎跟传统的UI自动化很有相似之处,是不是真的可以像我们客户那样用来做自动化测试呢?

RPA与UI自动化

研究了一阵UiPath的用法后,我给团队做了一个分享,用前面做的程序给大家演示UiPath的使用的时候,本来工作的好好的获取天气程序竟然挂了…原因是网页上的元素有了变化,重新修改获取新的元素路径才得以通过。

由此可见,RPA工具也跟UI自动化工具一样受到UI元素影响较大。

UiPath提供的图形化编程界面,对于没有编码技能的人来说,新建一个工作流拖拖拽拽就能完成,的确很方便。

但是,UI自动化测试都会随着UI的变化需要做相应的修改,通过图形化界面修改流程感觉还是有些麻烦的(或许是因为我还不够熟练使用这工具),作为QA,我更喜欢通过代码的方式来修改。而UiPath后台存储的是Xaml格式,可读性一般般,要改代码也没那么容易的感觉。

UiPath代码

另一方面,UI自动化测试最好跟持续集成工具集成起来,而主流的RPA工具都是不能在CI pipeline上运行的。

不像UI自动化工具那样运行于测试环境,RPA工具主要是适用于生产环境,基于相对稳定的系统来实现流程自动化。

当然,开源RPA工具TagUI,可以编程,也支持命令行运行,但是这个工具不太像是RPA工具,更像是被RPA耽误的UI自动化工具。

RPA工具用于UI自动化测试不仅没有太多的优势,反而带来很多不便,有杀鸡用牛刀之嫌,不合适。

对于自动化测试还是要基于测试分层理念,考虑尽可能把UI层自动化测试下移,对于必要的UI自动化测试也可以用更轻量级更适合的工具来做。

由于各种不适,我们客户用RPA工具做自动化测试的事情当然是没能达到很好的效果。

既然RPA不适合做自动化测试,我们来看看它的真正用途吧。

RPA技术的真正用途

RPA技术可以模仿各种基于规则而不需要实时创意或判断的重复流程,在电脑上不间断地执行基于规则的各种工作流程,它不仅比人类更快,还可以减少错误和欺诈的机会。简言之,就是“像人类一样工作”,“把人类进一步从机械劳动中解放出来”,让人类自由地开展更高价值的工作。这是RPA技术的初衷,是RPA技术的真正用途。

基于上述特点,RPA技术目前在财务领域应用比较成熟。财务是一个强规则领域,财务领域内的很多事务流程和报告流程大多是可重复、有规律可循的,因此也最易于实现流程自动化。在财务决策过程中相对标准化、有清晰的规则和可重复的活动,也可以应用RPA技术。

把财务相关的输入- 处理 – 决策 – 输出的流程进行分析、拆解,再用机器人软件模拟人的操作,把原本要在各种软件平台——包括会计软件、ERP软件、报表软件,甚至是CRM软件和税务软件上需要很多人力完成的填写、报送、执行命令、菜单点击、输出报表等动作,交由机器人来完成。这就是RPA技术在财务领域的应用场景。

其他基于规则的结构化的业务流程,也可以应用RPA技术,比如HR领域、保险报销流程等。目前,国内外已经有不少成功应用案例,例如:四大会计师事务所的财税机器人、阿里云RPA等。

PwC Robot

(图片来源:https://www.pwccn.com/zh/tax/tax-robot-solve-aug2017.pdf)

RPA,需谨慎前行

RPA技术可以用于结构化的基于规则的业务流程自动化,因此被认为是可以把人类从重复劳动中解放出来的技术,是一个完美的、高效的、低成本的数字化转型方案,被众多企业所青睐。

但是,RPA技术尽管颇具吸引力,目前的RPA产品仍存在明显的技术局限性,阻碍RPA项目发挥完全价值。 这些挑战包括:

  • 非数字流程输入的转换
  • 识别非结构化文档格式中目标数据字段的能力
  • 相对轻松地适应不断变化的规则或业务逻辑的能力
  • 从自动化流程的事务性数据中生成洞察的能力
  • 根据上下文解释和理解机器活动上游指令集的能力

RPA技术要跟AI技术结合,利用认知和智能识别技术来应对这些挑战,才能较好应用于数字化转型。

另一方面,仅从业务层去考虑利用RPA技术来实现数字化,容易忽略底层支撑系统的技术改造,并不利于整个IT环境的改造与企业的彻底数字化转型。2018年11月ThoughtWorks发布的第19期技术雷达,RPA第一次上榜,但是被置于“暂缓”环,正是这个原因。

RPA在技术雷达

技术雷达建议:

RPA这种仅关注自动化业务流程而不解决底层软件系统或功能的方法的问题在于,引入额外的耦合会使底层系统更改起来更加麻烦。这也会让未来任何解决遗留IT环境的尝试都变得更加困难。 很少有系统能够忽视变化,因此RPA的进展需要与适当的遗留系统现代化战略相结合。

同时,也有德勤、安永等咨询专家表示,就许多企业客户的流程管理与系统的基础能力现状来看,仍存在着大量的基础建设工作有待开展。不用着急实现RPA,首要的还是把自身的流程管理和系统构建好。

因此,RPA生态还不够成熟,暂不能作为理想的数字化工具。RPA要怎么用还是要根据企业自身特点和具体需求,谨慎前行,不可冒进。

数字化时代的软件测试

数字经济高速推动着一个无情的市场,所有利益相关者通过设备和应用网络进行交互,一个微观时刻足以让市场领导者摆脱优雅。 这种对速度的痴迷能否淡化质量定性方法?这份《World Quality Report 2017-2018》带你来一探究竟。

现代QA和测试部门重点关注的领域

敏捷和DevOps已经成为数字化转型的重要工具,同时,质量保障和测试工作也随之发生变化:

  • 中央治理和控制减少,团队选择方法和技术的自由度增大;
  • 部署速度提高和应用程序日益复杂化,软件错误和故障的风险增加;
  • 软件质量对品牌的影响巨大,但这已经不是最高优先级的目标,日趋成熟的尽早质量保障实践可以帮助纠正品牌和形象方面的缺陷;
  • 最终用户的满意度和安全性是最重要的两个方面,要确保应用程序的功能和非功能质量,同时需要找到成本和风险的平衡点。

调查结果表明,现代QA和测试部门需要重点关注的领域是以下三个方面:

1. 智能测试自动化和智能分析

智能测试自动化和智能分析将成为支持测试的关键,因为它们可以实现智能决策,快速验证和自动调整测试套件。测试自动化的范围从简单地将测试活动(计划、设计和执行)自动化发展到自动化测试环境和测试数据配置。

然而,调查结果显示目前自动化还处于不足的状态,尽管从自动化中获益的组织数量在增加,但产生的价值没有根本变化,测试自动化水平仍然很低(低于20%)。

速度将推动更智能的自动化需求,需要找到提高自动化水平的方法。

2. 智能测试平台

智能测试平台需要应对测试环境、数据和虚拟化日益增长的挑战。真正的智能测试平台的远景超越了生命周期自动化,需要实现自动配置的完全自我感知和自适应环境,以及支持自动化测试数据生成和测试数据管理。

测试环境、测试数据和虚拟化是三大挑战,同时也为自动化提供了巨大的机会。结合智能生命周期的自动化,将使QA和测试进入下一个演进阶段,称之为智能QA,这已经成为行业重要的关键成功因素。

3. 适应敏捷开发流程的QA和测试部门

组织需要关注的第三个领域是适应敏捷开发流程的QA和测试部门。在敏捷和DevOps模型中,测试从中心部门转移到分散的团队。未来的测试组织需要将灵活性与效率和重用性相结合,提供测试环境、测试数据、测试专业知识和技能的测试中心将分散到各种业务线的IT团队。

QA和测试的现状与挑战

从调查结果,总结出以下关于质量和测试现状的发现:

1. 回归对应用程序质量的关注,表明在敏捷环境的新上下文里,测试已经成熟

面对开发和测试环境的复杂性以及数字化转型的速度,关注点正在回归到整体产品质量上来,这是一个进步的迹象:

  • 参与这次调查的受访者中QA和测试人员明显多于其他角色,由2016年的37%上升到2017年的41%;
  • 2016年被引用最多的目标是在上线前发现缺陷,这个数字从40%下降到2017年的28%;
  • 最终用户满意度从39%下降到34%。

客户体验和增强的安全性处于IT战略的前两位。从2016年到2017年,增强安全性需求从65%大幅下降到35%。 IT成本优化进入今年IT战略的前三位,证明QA和测试能够应对过去几年的快速变化。

其他一些对IT战略意义重大的领域包括对业务需求的响应、实施软件即服务以及实施敏捷和DevOps。敏捷和DevOps实施需求的减少幅度超过一半,从38%的受访者减少到17%,这表明这些开发方法正变得越来越主流。

2. 测试自动化正在通向智慧、智能和认知QA之路

自动化尚处于待开发阶段,测试活动的平均自动化水平约为16%。自动化产生的价值在很大程度上没有变化。测试自动化不仅应该复制现有的手动测试过程,38%至42%的组织将认知自动化、机器学习、自我修复和预测分析视为测试自动化未来的有前途的新兴技术。

智能解决方案是DevOps、移动和物联网中的新趋势。通过增加智能自动化,企业适应快速变化的业务环境能力将得到增强。

3. 敏捷开发中测试的挑战不断增加
  • 99%的受访者在敏捷开发测试中面临某种挑战
  • 46%的受访者认为缺乏数据和环境是最严峻的挑战,这比2016年的43%有所提高
  • 在敏捷迭代中重复使用或重复测试的难度排在第二位,由2016年的40%增加到了45%
  • 挑战数量下降的唯一领域是:难以确定测试的重点以及测试团队在计划或初始阶段的早期参与。

测试和测试环境的自动化将帮助组织解决敏捷和DevOps开发模式给测试所带来的大部分挑战。 这些智能测试解决方案使得质量保障的速度能够适应日益复杂的集成IT环境。

4. QA组织不断演进以满足双峰要求

2017年,集中式的测试组织和分散式模型之间的分配更加均衡。在许多组织中,以前的卓越测试中心(TCoE,Test Center of Excellence)已经过渡到更加灵活的测试卓越中心(TEC,Test Excellence Center),其重点在于支持和赋能,而不是实际执行测试活动。

瀑布式开发仍将在未来很长时间内实施,形成与敏捷和DevOps混合的局面。例如,组织选择定位软件开发测试工程师(SDET)的位置时,其中敏捷Scrum和TCoE分别是36%和47%。

5. 环境和数据仍然是QA和测试的难点

调查结果显示有73%的组织采用云环境、15%的组织采用容器化来执行测试,使得测试的生命周期缩短。然而,仍有50%上下的受访者分别表示在测试环境管理、测试环境利用率、适用于敏捷开发的开发和测试环境,以及早期进行集成的环境方面存在挑战。

在测试数据管理方面,分别有超过50%的受访者存在以下挑战:管理测试数据集的规模、创建和维护合成测试数据、遵守与测试数据相关规定。

6. 测试预算下降,但预计会再次上升

专门用于质量保证和测试的IT总支出的比例为26%,它已经从2016年的31%和2015年的35%下降。

但是,随着组织采用敏捷和DevOps来支持数字化转型,未来两年质量保证和测试预算将会增加,企业必须确保IT应用程序的数量和复杂性,以及随之而来的QA平台解决方案的质量。

推荐的应对策略

1. 提高智能测试自动化水平

自动化是满足日益增长的数字化转型测试需求的关键,建议组织制定一个中心战略,确定企业首选的测试工具,确定自动化计划的战略业务目标,并确定衡量结果的指标。

同时,引入基于分析的自动化解决方案,向智能化QA和智能化测试自动化转变,以确保能跟上数字化转型的速度,做到持续的发展。

2. QA和测试部门转型以支持敏捷开发和DevOps团队

首先是组织结构方面的转变,QA需要与Dev和Ops团队一起,构建集成的DevTest平台,以实现持续的测试自动化。

测试人员专业技能也需要有所改变,要加强开发、分析和业务流程方面的技术专长,以适应敏捷和DevOps模式。

3. 投资智能测试和质量保障平台

在日益复杂的IT环境下,智能测试平台有助于企业做好质量保障工作。

  • 将智能分析和机器人解决方案引入测试流程和平台;
  • 提高容器化和虚拟化解决方案的水平和使用;
  • 投资于测试数据生成解决方案,以提供更多更好的符合所有法规的合成测试数据;
  • 将容器化环境,虚拟化服务和自动化测试数据集成到一个共同的可访问流程和平台中,组织可以围绕所有测试活动制定一致的方法;
  • 采用持续监测,预测分析和机器学习工具,利用生产环境数据,提供基于业务风险和实际问题定义测试策略。
4. 定义企业级测试平台战略

开源和服务化解决方案给质量保障和测试工具的选择带来了灵活性,但是,跨多个存储库数据连接和交换导致企业级质量状态缺乏透明度。

企业可以实施单一平台战略,指定一些技术为主要选择工具,或者创建最佳工具策略,可以涉及来自不同供应商的多种工具解决方案。

5. 定义企业级QA分析战略

前面提到过智能分析是重点关注的领域之一。为了从智能QA(智能测试自动化和智能测试平台)的投资中获得最佳回报,建议组织确定企业范围的QA分析策略。

这种质量保证分析策略决定了应该部署分析和认知解决方案的目标和领域,定义了跨QA操作的智能技术路线图。质量保证分析战略应与整体组织战略相联系,并应描述其如何实现整个组织目标。

:以上内容和图片均摘自这份《World Quality Report 2017-1028》,更多详细内容请参考原文。