聊聊:如何跟着团队一起转型？

背景

VUCA时代，敏捷软件开发模式已经被越来越多的企业所采用。在新的敏捷软件开发模式下，传统的质量保障方式也发生较大的变化，测试团队和每一位测试人员都将面临着转型带来的挑战。如何实现测试华丽转型，已经成为测试领域新的讨论话题。

一、传统测试与敏捷QA的差异？

那么传统测试和业务价值驱动的测试之间差异性：

维度	测试	QA
需求	功能需求	业务需求
目标	高效发现缺陷，完成交付	基于目标价值快速交付，投入市场
生产力	基于测试用例编写或执行	基于业务价值驱动测试来实现需求快速交付
计划执行	获得最大的测试覆盖率	基于风险考虑在最优时间内获得覆盖率
应对缺陷	响应式的机制，尽可能发现更多的问题	分析历史数据、缺陷和模式来预防缺陷
测试人员	验证问题、发现问题	预防问题、构建质量、数据分析

二、转型给测试的挑战有哪些方面？

目前业务团队转型将测试人员打散到各个研发团队，可能会使得测试人员茫然产生困惑。主要有以下几个方面：

• 归属感
  隶属于传统测试部门的测试团队习惯了以往的独立部门级管理方式，往往在加入各个不同的产品研发团队之后，找不到归属感。或者怀疑团队对质量的重视。

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

• 能力建设
  新的组织方式、开发模式，测试人员的能力建设也是面临很大挑战的问题，团队组织和甚至个人可能都不清楚目前需要具备哪些能力要求，也不清楚测试人员的能力提升路径。但是，往往这种模式下对测试人员的技能要求会比以往都要高而且全面。

• 团队协作
  在自身定位不清晰的情况下，也不知道该怎么跟不同的角色如何进行协作(团队角色赋能)，新的团队组织方式，如何去体现测试在团队中的价值，也是需要关注的一个点。

---

三、测试人员的能力如何提升？

由于团队组织架构的调整，测试人员所属团队的负责人一般都不是专业测试人员或者根本不是，对测试的技能要求并不是很清楚，他们只关注需求是如何高质量的快速交付。这种现状下，测试人员的能力就很难得到具体的体现和提升。

在这样的情况下，该如何进行自我提升呢？

• 个人成长角度
  从测试人员的个人成长角度来看能力提升，着重强调三点：

  • 海量知识
  • 提炼加工
  • 知识应用

  首先当我们有明确的目标需要去解决某个问题的时候，学习的效率会加倍的提升，效果会非常好。因此，找到提升的目标，以目标驱动去学习，从海量的知识里找到自己当下需要的部分，并且进行提炼加工、分类汇总、实践分享，这是最佳的学习指南 _{(读、写、讲、听)}

  至于目标可以参考一下几个方面：

  • 项目需求：项目可能正在转向微服务技术架构或者中台之类，那么就需要针对性地开展对应的测试。项目可能需要加强自动化测试，需要自动化测试技能。总之根据目前所面临的实际需求项目中去寻找目标。
  • 技术趋势：关注目前测试领域相关技术趋势，了解目前测试能做什么，深入学习。
  • 领导者的建议：作为领导者更清楚组织的发展需求，可以跟自己的领导去寻求建议，确定学习发展的目标。
  • 行业交流：多同行业人员沟通交流，尤其是行业佼佼者，尽可能参加一些技术峰会相关、网络技术公开课等。增强互动交流，让知识翻倍，做到持续精进，是加速学习成长的关键。
  • 跨部门协作：还有就尽可能去承担一些跨角色、跨部门、跨组织的角色，多去跟不同的部门沟通协调，从更广的视角去关注质量，持续提升自己的综合能力。

• 组织架构角度

  测试负责人TO需要承担起测试人员能力建设的职责，以下三个方面去开展能力建设工作：

  • 构建测试胜任力模型

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

  • 测试人员梯队建设

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

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

  • 构建测试社区

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

测试转型之四字真言"道器术法”

针对前面提到团队转型给测试带来的几个挑战，测试转型想要顺畅进行转变，参考以下几个层面:

• 测试转型之 ”道”

  认知层面：在团队组织架构改变的情况下，认知层面可能还有一大部分团队的测试人员是停留在以发现 bug 数量、按时完成交付为主要目标。而另一部分团队的测试人员的认知悄然发生改变，以持续交付更大价值为目标，很显然这种新的认知来进行需求交付更符合目前团队模式的现状。

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

  文化与认知的转变是测试转型最关键的层面，只有正确的文化认知才能指导后面三个层面的正确执行，才能真正地实现转型。当然，文化与认知是意识形态根本的转变也是最难的（毕竟没有人愿意被改变），思维模式转变在有效敏捷测试中至关重要。根深蒂固的认知要发生转变必须以持续学习，自我驱动成长的心态面对才有可能。

  理念与认知主要体现在以下三个方面：

  • 价值文化

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

  • 质量文化

    质量不仅仅是测试人员的事情，测试不再是质量把关者，团队人人都要为质量负责，做到全面地重视质量。 // 需要改变团队整体对质量负责的认知

  • 学习文化

    营造学习型的文化氛围，培养团队成员的成长型心态，实现持续精进，做到持续成长。关注团队成员成长，以持续提升为目的，鼓励团队成员创新、落地项目实践。关注结果的同时也应该关注过程。

  文化认知、质量策略、人员能力不能成为质量赋能路上的绊脚石

• 测试转型之 ”器”

  工具实践层面： 可以理解为在团队中如何合理有效的通过使用工具来提升测试效率、实现快速交付。

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

  测试高效的执行离不开好的实践和工具，可以从以下几个方面去分析：

  • 实践活动

    项目实践，主要是强调测试人员要以业务价值来驱动测试，项目实践与工具相结合，在提升效率的同时，更应该关注工具本身带来的预期价值。

    不同的实践活动和工具的采用要特别的注意，否则实践活动很容易流于形式化，造成一个局面就是，工具很容易被神化，为了工具而工具。

  • 工具方法

    测试工具种类繁多，接口、性能、安全、自动化测试、CI/CD pipeline 等其他相关，合理引用正确的工具才是助力质量提升的赋能利器。 会让整个软件交付过程更加顺畅，有助于效率提升和质量保障。

    建议去看下技术雷达《从技术趋势看质量赋能》这篇文章，其中有介绍DevOps系列相关工具的使用。

  • 精益测试

    只有认清实践背后目标的真正价值，才能让工具或实践带来应有的价值，只有真正理解引入的工具所能解决的问题本身，才能物超所值。而不是盲目模仿别人的实践，或者盲目的工具引用，最后得不偿失。

    另一方面，要特别关注测试的有效性，做到实时、适量、精准，也就是精益测试。 // 请参考 Thoughtworks 洞见文章《精益测试》28原则 敏捷四象限 分层测试

  工具不是万能的赋能利器，并不能解决问题本身，人才是最关键的因素。

• 测试转型之 ”术”

  流程策略层面：可以理解为测试如何有效的进行全流程介入：测试左移、持续测试、测试右移，贯穿了产品质量的整个生命周期。

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

  团队转型后的流程与策略可能跟传统模式相比会有很大的区别。强调三个方面：

  • 全流程介入

    测试全流程介入的开发模式，最关键的是如何做到测试左移、持续测试和测试右移。 // 分别请参考 Thoughtworks 洞见文章 《质量内建》《敏捷测试的核心》《QA 在生产环境下做什么？》

  • 轻量级策略

    测试策略文档要摒弃传统的冗长文档，而是采用可视化的一页纸测试策略，做到轻文档甚至去文档，根据实际情况灵活多变，重视文档背后团队内部的充分沟通和协作。并不是所有的测试项目都是需要测试策略的介入。 // 详情请参考文章《一页纸测试策略》

  • 演进式策略

    测试策略受影响的因素非常之多，需求项目本身、项目团队、人员成熟度、项目阶段，策略都会有差异，根据实际情况，去拥抱变化，实现策略的目标驱动和演进式发展。

• 测试转型之 ”法”

  组织沟通层面：区分团队组织沟通的方式，传统独立测试团队 Vs 敏捷团队的开发测试融合。相对来说，哪一种方式更值得提倡显而易见。但是，往往却很难做到。

  测试转型之法：组织沟通

  组织与沟通是相辅相成的，好的组织方式才能带来顺畅的沟通。体现在以下三个方面：

  • 组织架构

    推翻部门墙，组织架构调整团队融合，将测试人员打散到开发团队，组织架构的变化，实际上是为了更充分的沟通，沟通的充分和顺畅进行，才能发挥团队整体的最大价值。 // 目前团队确实是这样，但是是否真能发挥其价值？

  • 协作赋能

    在新的组织架构下，测试人员需要做到全程软件开发流程的参与，全方位与不同角色进行沟通和协作，以实现对不同的角色进行质量赋能。 // 具体可以参考一下《敏捷团队的质量保障赋能》

  • 构建社区

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

  团队质量保障赋能是大势所趋，团队组织需要引起重视

如何做到不能单纯的“形而上”，避免陷入“术”？道器术法四者兼备融合有多难?

逐步成为真正的 “QA”

关于敏捷 QA 的含义，有三个层次递增：

• QA = Quality Assurance 质量保障

  第一层次是做好质量保障工作，确保我们交付给客户的软件产品功能是符合预期的。这个层次的 QA跟传统测试人员的工作比较接近，主要在做质量保障执行层面的工作，包括理解需求，根据需求设计测试用例，执行测试。// 其区别在认知层面已经悄然发生变化，是质的提升。

• QA = Quality Analysis 质量分析

  第二个层次的 QA 通过测试、数据收集的方式，分析系统的质量，识别风险，并反馈给团队，和团队所有成员一起确保交付的质量是合格的。这个层次的 QA 除了设计并执行测试，还需要做很多的分析和协调工作，这也是敏捷团队 QA 的基本要求。 // 持续测试、持续反馈

• QA = Quality Advocate 质量倡导

  第三个层次的 QA 不再局限于只关注质量，通过培养对产品和流程持续改进的思维模式、了解产品的整体质量视图和持续关注产品质量的意识，引导整个团队构建正确有效的价值产品。这个层次要求 QA 能够承担其质量倡导者的职责，为团队进行质量赋能。

测试人员转型的最高目标就是成为这第三个层次的QA，通过分析软件风险并制定相应实践，确保软件在其整个生命周期中持续工作并创造价值，为业务和团队提供信心，从而为业务/客户提供价值。

QA 的所有实践和活动都需要以价值为核心来驱动，根据不同团队的具体情况可以适当调整，且在不同项目阶段应该也是演进式的。QA 跟各个角色的沟通和协作，也是随着团队成员的了解程度、配合默契度不同而有变化，并不是要求一成不变的。

---

最后

转型会很难、很痛，但是大势所趋，必须勇于面对。

只有主动拥抱变化、持续学习，以成长型心态积极面对，实现自我驱动成长，转型才有可能成功。

”淘汰” 将永远慢你一步，要记住："比你优秀的人，比你还更努力"，所以努力成为更优秀的人吧。

PS: 本次学习笔记是阅读 《不止测试》之后所感所悟，感兴趣的可以去看看。