小B是某业务方向的QA（Quality Assurance Engineer，质量保障工程师）负责人，该方向共3名QA同学，按双周对齐需求测试进展时发现，该方向有多个需求提测后需要等待几天时间，QA同学才能介入测试。虽然出现这种情况，跟该方向近期的需求数量变多有直接关系，但依然有两个可持续的改进方向：需求测试效率的进一步提升；部分需求应推动RD（Research and Development Engineer，研发工程师）自测，实行QA免测。

　　小D是该方向的一名QA，工作3年左右，对于这两个改进方向，他能理解，但也有一点困惑。需求测试效率提升很容易理解，因为效率提升后，QA资源能够尽快释放出来支撑新需求，这样就能减少需求的测试等待。具体如何提升，可以具体需求具体分析，先识别低效点，再进行针对性地改进。部分需求推动RD自测，实行QA免测的意义也很明显，本质上也是减少QA资源的占用，从而减少需求的测试等待。但对于如何实行QA免测，他完全没有思路，不知道该如何推动RD。因为需求实行QA免测，对PM的收益（需求能快速交付）和对QA的收益（减少资源投入、整体效率提升）是显而易见的，但是看不到对RD的收益，反而会增加RD一定的自测工作量。

　　小B针对小D的困惑给予了反馈：

　　推动他人协同时从他人的利益入手，思路是对的。但需要把站位进行拔高，眼光放长远，不能孤立地看待各个角色，也不能只盯着眼前的单一需求。对于任意一个业务模块的研发测试团队来说，交付效率高且质量符合预期是大家共同的目标，而如果不进行持续的、体系化的建设，研发和测试工作中的痛点会层出不穷，最终效率和质量目标也难以达成。因此，跟RD沟通时可以采取如下思路：

　　1. 意识宣导：推进需求QA免测所节省下来的QA资源会投入高杠杆率的事情，从而使该方向的体系性建设有资源保障；

　　2. 长期事项收益：针对该方向的研发效率和质量的挑战与痛点，输出相应的规划、里程碑等，推进过程中还需要让RD同学及时感知到阶段性的进展与收益；

　　3. 短期痛点解决：针对当前要免测的需求，QA需提供必要的支持，确保质量风险可控，且减少因为RD自测带来的额外工作量。

　　小D：懂了懂了，这个沟通视角不错，学到了。还有一点困惑，如何判断哪些需求应该免测呢？

　　小B：这个问题也很关键。

　　我过去在其他公司也推动过QA免测，效果不太理想。当时调研了常见的判断标准，如开发工作量、功能重要程度、代码改动行数等，发现这些指标都有一些明显问题，比如：

　　开发工作量小不代表改动的影响小、不代表改动的功能影响范围小，通过开发工作量小于1PD（Person Day，人日）或2PD，会漏掉很多需要QA测试的需求；

　　代码改动行数跟开发工作量类似，改动行数少不代表改动的影响小，根据此标准也会漏掉很多需要QA测试的需求；

　　功能重要程度，看似可以通过功能是否重要、是否容易产生重大缺陷来进行风险卡控。但实际上，需求难以轻松区分出重要还是不重要，像核心链路上的功能的确重要，很多功能是辅助作用，不太重要，但依然有很多需求不那么容易判断是否重要，这就导致研发和测试同学在判断时会花费很多时间讨论，且难以确定结果，如果无法确定结果，那默认就是需要QA测试了。

　　后来，重新调整了思路：根据日常协作中的认识和理解，把明确不需要QA测试的内容先明确下来，如为内部开发的工具、埋点需求、UI或文案的变更、日志相关需求等。针对具体的需求具体沟通，刚开始会有一定的沟通成本，但也会慢慢地沉淀出一些经验和体感。

　　小D：那新的思路运行得如何呢？

　　小B：整体还可以。核心还是要让RD能够把研发和测试当成整体去思考，同时让研发感知到自身的收益，无论是短期痛点的解决，还是长期事项的收益上。

　　小D：好的好的，咱们也搞起来吧，我很期待。

作者：软件测试技能栈    

来源：http://www.51testing.com/html/53/n-7801053.html