测试的行业危机

经常看到网上时不时吵起“测试人员如何转产品”、“QA的长期职业规划”等文章,对于QA工程师而言,貌似都是老生常谈的内容了。原本抱着在某个“特殊时刻”(马桶上)消磨时光的心态点开了这篇文章,居然在如此“恶劣”的环境下用时15min耐心看完了之后,又返回电脑前默默把它左击放入收藏夹。

到底这篇文章讲了什么呢?快收起小马步,听听华为资深测试专家怎么看待测试的行业危机:


入职华为以来,一直做的是测试工作,这种危机感在近几年愈发强烈,一直想总结一下,但又担心总结不好,动摇军心。但该面对的早晚要面对,需改变的也要尽早改变,一定要有革自己命的勇气。


危机的预兆

举两个测试行业危机的例子:

一个是外部例子。近期参加了几个测试行业交流,测试技术分享方面并没有什么新的发展,还是自动化、APP 测试能力技术分享。业界的测试专家也普遍进入一个迷茫期,很多测试专家转型敏捷教练、DevOps 流程专家。和几个专家聊了一下,也普遍感觉近几年业界对测试的关注已经逐步偏弱。

另外一个是内部的例子。华为 2017 年应届生招聘已经启动,在启动材料中,明确说明华为已经取消了软件测试工程师的岗位,HR 认为现在的软件需要全栈工程师,开发工程师也需要具备自测的能力。


危机产生的原因

测试行业发展的顶峰应该在 2000 年后,Google 测试体系大肆宣传的那几年,市面上到处都是 Google 测试的书籍,自动化测试能力也得到业界的高度认同,整个 IT 界都在推广自动化,一个测试专家仅靠自动化能力就会获得比较高的薪资。而近几年随着软件技术的快速发展,技术知识越来越容易获取,技术的迭代周期也不断加速,技术门槛也越来越低。在这种大背景下,专职测试的必要性也在不断受到挑战,特别对于一些创业类的小型公司,在没有专职测试的条件下,产品也能得到市场的认可。


随着软件开源社区的快速发展,软件工具的易用性也在不断加强,各类开发和测试框架层出不穷,技术人员可以很方便的使用框架代码实现自己的需求,按照公司的说法是我们无需自己造轮子。各种轮子的使用,让业务开发变得更加便捷,这也是为什么华为的软件可以使用大量合作的原因,也许不久的将来,这个行业真的会变成劳动密集型行业,未来受到冲击的可能不仅仅是测试和运维,开发一样存在在行业危机。


软件工程方法也在不断演进。以近期盛行的 DevOps 为例,该流程倡导一种全功能团队的运作模式,团队中的各个角色分工相对模糊,开发需要投入自测和运维,这种开发模式体现了及时响应,及时改进的快速迭代思想,提升了对开发的要求,但是对于运维和测试角色,造成了一定冲击。


传统的软件测试,特别是通信类产品和大型的 To B 类软件,对交付质量较高,有很高的门槛。一个测试专家需要了解无线交换、数通网络、小型机、软件、各类信令。专家到各地开局时,往往是单枪匹马,一人搞定,受到办事处同事的敬仰膜拜。记得有次给客户演示 VPN 短号,业务服务器故障一直无法定位,征得客户的同意,直接在交换上做了一个号码变换,先解决演示的问题,当时测试人员要求的技术广度远超于开发人员。


但是近几年,通信业已经无法阻挡软件化的趋势,随着 CT 技术门槛也在不断降低,华为也正喊出了 CT 转 IT 的口号。软件的微服务、云化等技术,让测试人员工作也不断简化,很多新来的同事对直接使用计算云部署环境,对物理服务器的了解也是一知半解,在知识广度方面可能和开发持平,而在深度方面,又不如开发,测试技术不在存在门槛,角色的必需性正在不断的弱化。


华为测试人员的现状

华为大部分部门的测试开发比在 1:3 或 1:4 这个比例,这在业界是比较高的,比例高有两方面原因,一方面是和我们的通信软件质量要求比较高有关,需要多轮的验证,需要大型解决方案的交付。另外一方面和华为的 IPD 流程相关,大量的测试交付件,大量的评审和会议,为了确保大家步调的一致性,行管部门还是定期进行飞检和数据晾晒。严谨的流程保障也是有利有弊,从好处来看,可以确保软件的质量不会出现大的问题,适合软件开发的大兵团运作,弊端来看,严重影响到软件的生产效率。


从华为对测试角色的定位看,测试需要承担三种职能角色,一种是管控角色。测试人员就像就像沙丁鱼箱中的鲶鱼一样,不断的通过各种数据,各流程,驱动上游团队持续的保持活跃,进行相关的改进。并且测试作为研发的一个环节,本身也要提供相关 TR 点的素材,配合提供项目的各类测试交付材料。在大型的团队中,这部分的流程和数据还是非常受到领导重视,因此也产生了很多华为自有测试员工,过于投入流程和数据,而忽略业务本身的现象。


第二种角色是质量服务角色。就是测试要对产品投入实际的测试执行工作,发现版本的质量问题。在华为传统观念中,测试部应该对产品的质量负责,负责的重要标准就是测试部需要对版本进行一次完整测试,需要输出相关结论。在华为和开发和测试分工中,也是基于一种不信任的配合关系,测试人员不需要关注开发测试过程中已经验证了什么,版本转测试后,测试必须完整版本验证工作,从部门的角度给出最终的结论。而这种测试定位,在互联网领域中,已经逐步的弱化,只有关键的产品才会投入专职的测试专家进行测试设计和执行工作。


第三种是工程能力角色,类似 Google 的工程生产力部门,定位为提升研发过程效率和质量,输出相关工具和方法的支撑,提升整个研发过程的测试效率。目前这部分的专家主要集中在 2012 实验室和几个大产品线的工具部。而产品测试(业务测试)投入的能力建设,主要集中在 DFX 的特性测试以及自动化能力方面。


对于华为传统的 To B 类产品,测试投入的 1、2 两个角色职能的工作非常多,也占用了业务测试团队的大量时间,特别对于具体的测试执行,各产品线业务测试投入大量合作员工进行基础的测试保障。对于工具和测试能力的提升,2012 实验室的测试行业投入较多,在 6+1 测试工具有了一些成果,但是能力和业务还是有一定的脱节,行业专家不会介入业务太深,业务定制化的测试需求也较多,导致很多实际的业务测试效率问题,仍然需要业务自身解决。


我所在的云服务属于公司内少有的 To C 类产品。我们所有的产品都是无需向运营商交付的,对自有业务需求的控制比 To B 产品好太多,也可以在我们自有的环境上进行灰度发布,Beta 测试,很多快速交付的实践都在产品中落地,因此可以做到每月至少一次的迭代发布。


但是对于云服务测试来讲,也仍然面临的较多的问题。我们的测试开发比在 1:7 到 1:10,基本上一个人负责一个或者多个模块的测试,在华为的质量体系下,我们也是要遵从华为一些质量交付件,例如云服务需要与 EMUI 进行版本的配套,相关的测试交付还是要参考 IPD 的流程,所以在流程工作的投入上,测试人员投入的仍然很多,各类的会议也是很多。安全交付件更是如此,这是公司的红线。在组织职责方面,测试和开发的组织职责也可以相对独立,不存在开发自测交付的概念,在版本交付后,所有的测试的工作需要测试部独立承担,包括外部采购的合作项目,可能开发需要投入一个 PM,但是测试要完成所有验收。未解决测试执行覆盖的问题,也是大量使用了合作员工,合作自有比也超过 5:1,合作的流失和培养一直都是历史难题。


因为团队规模比较小,能力建设方面也主要采用合作的模式,依赖外部的测试能力和 2012 的团队,来推进云测, 6+1 等方面工作合作,测试的重点依然的是自动化,DFX 等方面。而对于业务体验等方面关注的力度并不足。交付类测试仍然是我们工作的主要方向


业务测试人员的

发展方向

虽然前面讲了很多测试的危机和问题,但是从行业发展的必要性来讲,测试是质量的重要保障,测试行业不可能被淘汰,我们只需要考虑如何让我们的行业价值更高,让自己不会被这个时代所抛弃。


公司一直倡导的都是工匠精神,但是软件行业和传统的手艺不同,我们所使用的工具在不断的变化,十几年前,我们还在使用 Basic、Pascal,但是现在已经是 Java 的天下了,软件的工匠精神不是比拼的是对语言和工具的熟悉,更多的在于软件系统的经验。


测试的定位,不是仅仅发现版本的问题,或者做简单测试技术工具的投入,而是应该定位更高一层,测试是整个产品的质量守护者,需要具备提前预防质量风险的能力,应该具备推进产品测试技术改进的能力,也应该具备产品研发过程中(含开发环节)测试效率提升的能力。测试能真正从客户角度去看待和发现问题,并推动客户质量满意度的不断提升。这个定位很高,实现过程也很难,我们现在普通的测试人员 80% 都是在测试的具体执行和一堆的事务性工作上,每日都在加班加点,很少有沉下心来分析问题的根因,通过学习不断寻找技术改进的方向。


从测试技术发展来看,测试的工具化或自动化肯定是未来的趋势,自动化的比例会不断的提升,但是机器的自动化短期内无法实现完全脱离测试人员的,仍然需要人工接入进行相关的自动化设计。从执行的特点看,测试分为两类,一类是固定场景的验证,一类是未知场景的探索。


对于固定场景的验证,有预期的输入和输出,无论是接口测试还是 LLT (底层测试),都是具备这个特点。测试人员的重点是将具体的场景抽象为自动化用例,提升回归测试的工作效率。对于基于 UI 的自动化,因为产品可能存在较大变动,UI 识别也存在部分确定性,我们可以量力而行或尽可能抽象为接口自动化。在自动化工作中,测试要对开发有足够的可测试性要求,产品具备良好的代码解耦的架构。


对于未知场景的探索,主要是针对没有对应测试设计的测试驱动。可以分为工具类的自动化探索,例如我们手机可靠性测试使用的 monkey,以及安全测试的 fuzzy 等。测试的场景由工具生成和决定。另外一种是人工的探索测试,这个概念近几年也比较盛行。但个人认为这种在可行性上还是有一定难度,对测试人员的经验要求较高,目前我们也并没有组织,主要通过 Beta 测试,引入大量普通用户完成各类场景的探索。


任何测试都是不能 100% 发现问题,网上问题的发生也是很难避免,测试需要尽量降低网上问题的级别和发生概率,并且需要具备较高质量风险防范的意识,对于高风险产品必须有双重(或三重)的防范机制。例如我们做一个支付类产品,可能会在存在某些质量问题,导致用户未支付的情况下,支付状态进行了更新(这个例子可能大家感觉不会出现,但是现实中有各类可能)。测试人员必须对产品提出,有额外的管控系统,对账号进行准实时的核查比对,确保收支一致。互联网有过类似的安全,2012 年某东积分兑换 BUG 的问题轰动一时。好的测试专家需要像扁鹊大哥一样,尽可能的识别和规避可能的质量风险。


测试人员的技能模型应该保持多样性的发展,在广度方面不断延伸,深度方面可以选择一两项技术进行不断挖掘。有三点需要测试重点关注:


编码能力:特别对于新员工,这个能力是与开发有共同语言的基础。测试人员需要了解对应业务的代码框架,构建工具,以及 LLT 测试,持续推动开发过程中的改进,能给予代码提出测试建议,将质量构建在开发阶段。


组网能力:测试需要对系统的组网,以及实际的部署情况有清晰的技术理解,这样才能发现更多的质量问题和隐患。这个说起来是比较简单,但是如果做到深入的了解,还是有很高的技术难度,例如我们现在各个业务使用的 CDN 和 DNS,如何组网可以让我们的系统体验会更快更好。用户使用的 UC、QQ 浏览器等是具备缓存加速,在缓存场景下是否会对某些业务特性产生影响。


业务能力:测试不能脱离业务,这也是为测试人员未来转型产品经理或其他岗位的一个必备能力。无论开发还是测试,能在整个职业生涯中,坚持到底的,是少之又少。大型产品线如有测试系统部之类的部门,如果脱离业务,纯粹投入技术规划或流程规划,往往会逐步被产品边缘化。


产品会有各类的隐患和问题,测试人员如果长期只发现简单的 BUG,不仅会让技能水平下降,而且会失去对工作的兴趣,我们只有通过工具或技术不断解决问题,才能挖掘测试工作的乐趣。

小编读后感

我想到了前一段读的一篇文章中提到《探索式软件测试》一书,作者 James Whittaker结合自己二十年的经验,从多个角度结合实例阐述了探索式软件测试的创新意识。他把测试职业发展的道路比喻为爬山,从初学者阶段到专家阶段之间存在着一个“测试的山峰”,人们需要通过一系列个人辅导、获取信息和接受常规指导来翻越山峰。成为一个测试初学者是很容易的,成为职业的测试人员也并不艰难,最难的是,如何翻越那座位于职业测试人员和测试专家之间的山峰。


随着互联网的电商、金融等公司蓬勃发展,这些公司的技术团队的规模也快速增长,应用规模快速扩大,测试环境日益复杂,测试力量也在不断变化,应用验证成本不断提升,软件产品的质量含义也在变。在之前的专栏中,百度资深测试工程师永哥也和大家聊了聊“软件质量的变迁”(点击查看原文),他提到:

永哥说:

在不同发展阶段,移动互联网产品对质量的要求,对于QA测试团队的要求,会有不同。IT软件产品质量的好坏,最终是由用户可感知的真实体验决定的。用户体验好,产品服务稳定,几乎就是用户眼里的质量全部,决定了产品的用户认知。因此,QA工程师精力应投入在哪儿,根据产品发展不同时期,值得不断review,及时做出调整。所以,QA工程师和QA团队需要不断平衡程序bug、服务质量、产品品质三者关系,发挥QA懂业务场景、懂技术实现的特点,为用户代言,为产品品质代言,对产品的最终成功发挥保驾护航的作用。

所以:

千万千万不要把自己只当成一个纯手工测试人员

千万千万不要把自己只当成“找到最多缺陷的人”,而是“找到最有意义缺陷的人”

千万千万不要把自己只当成找bug的工程师,而是服务质量和产品品质的守护者


如果你看的意犹未尽,如果你想随时随地充实自己,请扫描以下二维码,关注我们的公众账号,可以获取更多技术类干货,还有精彩活动与你分享~


大咖招募
欢迎App研发/测试方面的大牛来投稿,开设专栏。我们提供丰厚的稿酬,预约个人专访,帮助建立个人技术品牌!
立即投稿

我要评论

字数不能超过140字,谢谢!
提交

评论({{allComments.length}})

{{comment.create_time.substr(0,16)}}

显示所有评论
你好,请问有什么可以帮助您?