入职华为以来,一直做的是测试工作,这种危机感在近几年愈发强烈,一直想总结一下,但又担心总结不好,动摇军心。但该面对的早晚要面对,需改变的也要尽早改变,一定要有革自己命的勇气。
  危机的预兆
  举两个测试行业危机的例子:
  一个是外部例子。近期参加了几个测试行业交流,测试技术分享方面并没有什么新的发展,还是自动化、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% 都是在测试的具体执行和一堆的事务性工作上,每日都在加班加点,很少有沉下心来分析问题的根因,通过学习不断寻找技术改进的方向。
  从测试技术发展来看,测试的工具化或自动化肯定是未来的趋势,自动化的比例会不断的提升,但是机器的自动化短期内无法实现完全脱离测试人员的,仍然需要人工接入进行相关的自动化设计。从执行的特点看,测试分为两类,一类是固定场景的验证,一类是未知场景的探索。