查看原文
其他

数字化转型背景下的测试转型

林冰玉 BY林子 2022-03-17


读完需要

15分钟

速读仅需 5 分钟

数字化转型强调业务价值驱动、以技术为核心,传统的业务部门和研发部门都会在转型中得到重视,而传统的测试部门因为得不到相应的关注和指导,通常会处于尴尬的局面。

在这样的大背景下,如何帮助测试团队顺利完成转型备受关注,本文将跟大家一起探讨这个问题。

👀

   

01 数字化转型给测试带来的挑战

转型让测试人员打散到研发团队,通常使得测试人员茫然无措,非常地不适应。与众多转型企业中的测试团队沟通后发现,测试转型面临的挑战主要有以下几个方面:

归属感

隶属于传统测试部门的测试团队习惯了以往的部门级管理方式,往往在加入各个不同的产品研发团队之后,找不到归属感。

职责定位

融入研发团队的测试人员面临新的工作方式,不清楚自己的职责和在团队中的定位,不清楚哪些事情是需要做的,发挥不了应有的价值,从而导致话语权低,在团队没有影响力。

团队协作

由于不清楚自己的职责定位,也不知道该怎么跟不同的角色进行协作,这种新的团队组织方式,让测试人员担忧。

能力建设

新的组织方式和开发模式下,测试人员的能力建设也是面临很大挑战的问题,组织和个人都不清楚测试人员的能力要求,也不清楚测试人员的能力提升路径,而对测试人员的技能要求比以往都要高都要全面。

👀

   

02 测试转型的道法术器

面对前面提到的几个挑战,测试转型想要顺畅进行,想要从以下几个层面去实现转变,我把它们称为测试转型的道法术器,如下图所示:

先通过几个小例子来直观感受一下:

测试转型之器——工具实践层面: 如果有两个组织分别采用全手动回归测试和全自动化回归测试,毫无疑问,是那个自动化回归测试的组织实践更好

全手动回归测试(❌) vs 全自动化回归测试(✔️)

测试转型之术——流程策略层面: 如果在那个全部自动化回归测试的组织有两个部门,一个是产品开发完成后有独立的测试阶段,另一个是测试左移到需求分析阶段,并且全流程介入,我们会说第二个做到了测试左移的部门的流程策略更好

独立的测试阶段(❌) vs 测试全流程介入(✔️)

测试转型之法——组织沟通层面: 如果在那个有测试左移的大部门分别有两条研发产品线,其中一条的测试是一个独立的团队,而另一条的测试人员跟开发组建为开发团队,测试开发进行了融合,那么,进行测试开发融合的产品线的组织沟通方式更值得提倡

独立的测试团队(❌) vs 测试融入了开发团队(✔️)

测试转型之道——文化认知层面: 虽然进行了测试开发融合,但是在文化认知层面还有一部分团队的测试人员是停留在以发现 bug 为主要目标,而另一部分团队的测试人员则以交付更大价值为目标,那么那些关注交付价值的团队一定会带来更大的价值交付

以发现更多 bug 为目标(❌) vs 以交付更大价值为目标(✔️)

下面更详细的介绍道法术器每个层面都有哪些内容。


   

测试转型之道:文化与认知

文化与认知的转变是测试转型最关键的层面,只有正确的文化认知才能指导后面三个层面的正确执行,才能真正地实现转型;当然,文化与认知的转变也是最难的,根深蒂固的认知要发生转变必须以终身成长的心态来面对才有可能实现。

文化与认知主要体现在以下三个方面:

价值文化

以交付价值为目标,测试要以业务价值驱动,关注整体的质量,不再是以发现 bug 为目标,bug 要做到预防为主。

质量文化

质量不仅仅是测试人员的事情,测试不再是质量把关者,团队人人都要为质量负责,做到全面地重视质量。

学习文化

以持续提升为目的,鼓励团队成员创新,允许试错,允许失败,只有经历过失败,才能获得更大的成功;营造学习型的文化氛围,培养团队成员的成长型心态,实现持续精进,做到终身成长。


   

测试转型之法:组织与沟通

组织与沟通是相辅相成的,好的组织方式才能带来顺畅的沟通。组织与沟通同样体现在三个方面:

组织架构

推翻部门墙,将测试人员打散到开发团队,这种表面上的组织架构的变化,实际上是为了更充分的沟通,我们需要促进沟通的充分和顺畅进行,发挥团队整体的最大价值。

协作赋能

在新的组织架构下,测试人员需要做到全周期的参与,全方位的与不同角色进行沟通和协作,以实现对不同角色进行质量赋能

构建社区

打散了的测试人员分属于不同的研发团队,构建一个横向的测试社区非常关键。这个社区可以制定组织级质量保障策略,构建测试胜任力模型;一起探讨解决质量保障过程中的难题,实现质量知识的共享,让测试人员抱团共同成长。


   

测试转型之术:流程与策略

转型后的流程与策略跟传统模式相比会有很大的区别,详细的内容可以参考【林子的空间 ( https://www.bylinzi.com )】中关于敏捷测试的相关内容介绍。这里还是强调三个方面:

全流程介入

测试全流程介入的开发模式,最关键的是要做到测试左移、持续测试测试右移

轻量级策略

测试策略文档要摒弃传统的冗长文档,而是采用可视化的一页纸测试策略,做到轻文档,重视文档背后的充分沟通和协作。

演进式

测试策略受影响的因素非常之多,不同项目团队、不同人员成熟度、不同的项目阶段,策略都会有差异,需要拥抱变化,实现策略的目标驱动和演进式发展。


   

测试转型之器:实践与工具

测试的成功执行离不开好的实践和工具,这个层面也是大家比较容易接受和较多的采纳的。同样从三个方面来看:

实践活动

实践活动,主要是强调这么几条原则:测试要以业务价值驱动,基于业务优先级来开展测试,让测试更有价值;关注整体质量,要从整体视角去看质量,而不是把注意力放在某些细节功能模块上;缺陷要做到预防为主,不再是关注后期发现缺陷的数量。

工具方法

工具主要有自动化相关的工具,包括测试自动化和流程的自动化;持续集成流水线以及流水线上的标准化工具也是助力质量提升的赋能利器;另外一个就是 DevOps 系列工具的采纳,让整个软件交付过程更加顺畅,当然质量也会更有保障。

精益测试

但是,不同的实践活动和工具的采用要特别的注意,实践活动很容易流于形式化,工具很容易被神化。我们只有认清实践背后的真正价值,才能让实践带来应有的价值,只有真正理解工具所能解决的问题,才能物超所值;而不是盲目模仿别人的实践,或者盲目的采购工具,最后得不偿失。

另一方面,要特别关注测试的有效性,做到实时、适量和精准,也就是精益测试

👀

   

03 测试人员的能力提升

由于组织架构的调整,测试人员所属团队的负责人一般都不是专业测试人员,对测试的技能要求并不是很清楚,很难对测试人员的能力提升起到关键作用;另一方面,原来的测试负责人,由于不直接跟测试人员在一起工作,对测试人员的能力提升也是爱莫能助,感觉使不上劲。

在这样的情况下,该如何面对挑战呢?我们分别从组织角度和个人成长角度来探讨。


   

1. 组织角度

从组织的角度,测试负责人需要承担起测试人员能力建设的职责,可以从以下三个方面去开展能力建设工作:

构建测试胜任力模型

对测试技能需要进行整理和分类,构建不同级别的测试胜任力模型,以此作为测试人员的成长路径指南。胜任力需要将行业趋势和组织内部业务、技术需求相结合,形成适用于不同层级技能的测试人员,比如有测试必备技能、进阶技能和高级技能等。

测试人员梯队建设

基于胜任力模型对测试人员进行针对性的培养,构建短期快速胜任和长期持续胜任的能力,建设健康的测试人员梯队,做到可持续的培养和发展。

测试人员的能力培养同样需要遵循知识->经验->能力的提升路径,并且与测试人员的自身优势结合。创造环境,鼓励测试人员将知识应用到实际项目中,形成经验积累,以最终发展为解决问题的能力。

构建测试社区

前面测试转型之法部分已经提到构建社区,对测试人员能力建设非常关键。通过这个社区,可以实现前面提到的测试胜任力能力模型构建和测试人员梯队建设,帮助测试人员构造能力提升路径。


   

2. 个人成长角度

从测试人员的个人成长角度来看能力提升,之前有文章详细讲过这方面的内容,这里着重强调三点:

以终为始,持续学习

当我们有明确的目标需要去解决某个问题的时候,学习的效率会加倍的提升,效果会更好。因此,找到提升的目标,以目标驱动去学习,从海量的知识里找到自己当下需要的部分,并且进行提炼加工,应用于实际工作中,这是最佳学习路径。

目标来自哪里呢?

目标可以来自于三个方面:

  • 项目需求:项目可能正在转向微服务技术架构,需要针对性地开展微服务测试;项目可能需要加强自动化测试,需要自动化测试技能。

  • 技术趋势:《ThoughtWorks 技术雷达 ( https://www.thoughtworks.com/cn/radar )》或者《全球软件质量报告》都是不错的技术趋势指南。

  • 领导者的建议:作为领导者更清楚组织的发展需求,可以跟自己的领导去寻求建议,确定学习发展的目标。

增强互动交流

增强互动交流,让知识翻倍,做到持续精进,是加速学习成长的关键。要做到跨角色、跨社区/部门、跨组织的沟通,从更广的视角去关注质量,提升自己的能力。

成为真正的“QA”

测试人员(QA)需要成为质量倡导者,为团队进行质量赋能,这个话题提过很多次了,不再赘述,再次上图加深印象。

更多详情,可以参考《敏捷团队的质量保障赋能》和《从技术趋势看赋能 》。

👀

   

04 写在最后

转型会很难、很痛,但转型也是大势所趋,必须勇敢面对。

只有能够拥抱变化,以成长型心态面对,实现终身成长,转型才可能成功,才可能不会被淘汰。


推荐阅读:

  1. 敏捷测试宣言与原则解读

  2. 敏捷测试的核心

  3. 测试要以业务价值驱动

  4. 敏捷测试的指导性原则:团队整体为质量负责

  5. 一页纸测试策略

  6. 精益测试

  7. 测试右移

  8. 敏捷团队的质量保障赋

  9. 从技术趋势看质量赋能

  10. 软件测试人员该何去何

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存