背景
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: 本次学习笔记是阅读 《不止测试》之后所感所悟，感兴趣的可以去看看。
网友评论