“缺陷预防”的结构化解读

缺陷预防为讯飞AI营销技术的重要测试实践，相关实践内容曾先后登陆至MTSC2019和TOP100 2019的大会进行分享。以下对缺陷预防进行结构化的解读，共享给各位读者同仁。


定义
缺陷预防是可用于整个软件开发生命周期或需求交付的整体交付过程，特别是在版本/需求提测前能够有效减少缺陷引入或防止类似缺陷再次出现的策略、方法和实践。通过缺陷预防能力的建设实现质量在上游的内建，有效减少上游引入的过程缺陷，从而改善产品需求整体交付能力。


观点
缺陷是研测阶段最重要的产物，虽然重要，但并不是一个项目在交付测试阶段发现的缺陷越多越好。如下图所示，缺陷在需求阶段若被发现并处理，所带来的成本影响还比较小；但缺陷若在测试环节识别解决，修复缺陷的成本是指数级式增加表现。根据缺陷的群集现象，测试阶段发现的缺陷越多，所可能隐藏的缺陷也会越多，将会增加线上的风险。
<center></center>
缺陷预防能力的建设，能够让测试职能从原有被动式事后发现缺陷的工作开展模式往“事前、事中、事后”的主动式全方位工作开展模式实现过渡，实现测试职能的价值最大化。
关于缺陷预防能力的建设，不同的组织、不同的业务背景所采用的措施不尽相同，需要结合自身组织的现状推进相关能力的建设。一般情况下，以项目中实际存在的切身问题作为切入点，通过切入点引入改进措施，实现缺陷预防能力的建设。
这里举一个当初笔者所推进的缺陷预防能力建设一个实际的切入点案例。
项目初始面临的很突出的问题：研发侧对自身交付提测产物的质量关注不痛不痒，提测行为随便；不自测就直接交付给测试侧进行测试；测试侧在这样的情况下，在常规正常功能流程下就能发现较多的低级缺陷、严重缺陷，测试花更多的时间在低级问题、阻碍型问题的反馈跟踪处理上，让我们无法挖掘更深层次的缺陷。在这样的背景下，测试职能获得的成就感一般。
为此我们建立了版本质量度量体系，通过度量体系的建立，使每个研发提交的构建版本都有个质量上的可视量化呈现，并通过透明公开和绩效影响，促使研发侧认知质量也是研发交付的必要特性，建立良好的交付习惯，对自身的交付质量负责任，促使研发建立基础的测试思维。这套体系最初落地时，我们曾做过一个统计，版本开始提测到满足最终上线能减少30%的时间周期跨度，也就是原来3天的测试周期，体系推进后因为实实在在的缺陷降幅，使我们的测试周期能够缩减到2天。


岗位胜任力概述
这里从全局视角、洞察能力、沟通能力、推动能力四个重要的能力要素进行阐述；
全局视角：测试职能开展业务的测试工作，在深入业务细节测试的同时，也需要跳出来审视整体的测试工作。测试工作是被动式的守株待兔式的接受来自上游的交付，从中发现缺陷。还是可以主动出击，主动参与整体交付过程的过程质量建设。从全局来审视，主动出击对业务的整体交付效果和对测试自身整体工作的开展明显会更好。但主动出击需要测试职能适当推进打破部门墙和自身职能既定范围的一些限制，需要必要的勇气决心。
洞察能力：缺陷预防的更多涉及到整个交付流程的相关问题的优化建设。在满足上文提到的全局视角审视整体质量保障工作的条件时，我们需要站在整个项目交付的主人翁视角去洞察整体交付的环节和过程中所可能存在的问题。更重要的是通过表面的问题现象能够窥探其引起此问题的本质原因。如研发交付质量差，这是一个问题的笼统描述，但引起质量差的原因可能是多样的，如业务知识掌握不足、团队新人较多、自测交付意识差、交付特性需求比较大等等，需要去洞察引起问题的最主要的原因。
沟通能力：缺陷预防能力的建设，涉及到产品、研发等外部职能角色的配合参与，更有些时候相关措施的落地，会增加对方的额外工作投入，且可能还会影响对方的绩效。故如何说服对方职能参与到缺陷预防的建设中来，需要相对有效的沟通能力和技巧。沟通前需要对相关的问题进行了明确的洞察，并给予自身的思考和经验，能够输出切实可行的落地措施方案，沟通时要站在整体项目交付的高度，具有同理心的与对方职能人员进行透明坦诚沟通，探讨相关解决方法。一般情况下，措施的探讨落地，一般由测试组长级别人员发起，并邀请研发组长和产品经理共同参与，从上层达成改进措施方案，由上及下的推进落地。
推动能力：项目中存在的问题，有些时候并不难以发现。重要的是发现后积极寻找对应的解决方案并推进落地。落地措施需要得到相关参与方的共识和支持。在过程中难免会遇到一些阻力和困难，比如措施落地的引导问题、部分成员的反对意见等，在正确的道路上顶住压力很关键。同时在推进的过程中，为了更好的落地，我们需要对推进效果阶段性的审视、对过程中存在的问题也要积极的解决，不断优化落地。


学习建议
这里提供笔者所在的业务重点推进的缺陷预防能力建设的5种相关措施，供读者启示，期望带来抛砖引玉的作用。
1、通过建立版本质量度量体系，让质量成为研发的“紧箍咒”，研发提测不再儿戏。让每个版本的质量具有质量水平的可视化能力，通过度量结果的公开公示和相关的绩效激励影响，促使研发侧重视自测，重视自身交付产物的质量。以下呈现我们的实践步骤：
a、共识度量标准；不同的方向和不同的交付研发模式，其度量标准有一定的差异，如前端、服务端的缺陷密度是不一样的，不能一刀切，结合现状和实际来制定标准；我们是采用先建立基准度量指导标准，从哪些度量维度展开，然后各方向根据自身需要定制，以加分激励为主；通过度量标准让版本质量具有了可视能力，不再是仅有的缺陷感知；
b、研发绩效激励；有了单个版本的度量，那么每月每个人的综合度量就出来了，这里面自然有了高个子和矮个子，那些矮个子就会有种压力要提高自身的质量交付水平，高个子也会继续努力，不断突破；我们会把每月度量汇总结果，进行团队内公示，形成内外部关注。更重要的是要把相关质量加分变现为研发绩效加分，尝到甜头，让那些质量加分明显的同学能够获得绩效优势，营造研发内部质量内建的风尚；把抽象的质量意识转化成为了实在的可触摸的绩效，去促进高质量版本的诞生，从而达到缺陷预防的目的。
c、弹性拔高标准；随着度量体系的落地，研发的质量交付水平是有提高的，所以基于这样的情况，我们需要阶段性的审视对度量标准进行优化和必要拔高；

2、通过版本交付测试规范，解决设计文档交付问题引入的低效沟通、低效协作问题，增强研测交付顺畅度；借助设计材料交付规范化和提前交付规则，促使业务测试提前掌握设计细节，提前进行测试准备和相关问题识别防控。借助版本发布构建的规范化，优化多人协作模式下的代码提交和构建报告的漏写、错写现象。
以下呈现我们的实践步骤：
a、敏捷不是不需要文档；建立规范前，首先要解决引导的就是错误的概念性的理解偏差问题，我们知道《敏捷宣言》强调“工作的软件高于详尽的文档”，是不是文档不再需要了，或者说为了强调速度、强调快，我们就砍掉文档建设了。当没有必要的文档建设时，我们就会面临着低效沟通、低效交付、高风险问题，长久来看也会影响到团队的业务能力传承。为了增强研测交付顺畅度，我们主要推进了2个交付材料的规范化，分别为设计材料说明的规范化和版本发布构建的规范化；
b、设计材料说明规范化；通过设计材料说明的规范化和提前交付规则，帮助测试成员提前获知研发设计实现细节，快速提前进行测试准备；这些内容的提前获取一方面测试成员可在准备过程识别到风险或漏洞及时快速反馈，避免遗漏到测试环节才发现。同时有效减少测试环节未知信息阻碍型的因素，测试工作的推进更加顺利，整体测试工作也更加主动；设计材料的颗粒度以及结构可通过传递优秀的案例进行引导；设计材料不是文字越多越好，越易懂越好；我们曾统计一组数据，因为这个措施，测试职能掌握理解整体需求的时间可以缩减50%；
c、版本发布构建的规范化；这个规范化来源于1次现网故障，研发同学因在代码中增加了仅仅一行与交付功能完全无关的测试代码，构建未说明，测试基于功能范围评估也无法测试到，问题就引入到了现网；所以针对版本发布构建，研测双方进行了强化规范，形成更有效的发版处理机制，对多人模式合作下的代码提交提供了规范要求，同时也对版本发布需要包含的要求进行明确引导规范说明；使整体交付说明更完整具体；减少构建报告不准确不完整的问题隐患，比如说没有说明影响范围、内容有错写和漏写，甚至代码还有多提交和少提交的情况。这次现网故障也额外加速了测试侧精准测试能力的落地；

3、通过需求解耦版本切割，减少大而全需求的集中交付，实现需求上的降解和必要减法，实现版本上的提测的灵活控制，降低研发测试交付难度，进一步实现小步快跑。
以下呈现我们的实践步骤：
a、问题原因认知；大而全的交付，场景分支太多，存在考虑不周的情况是很容易存在的，同时大而全的交付，一般也涉及到多人联合开发，开发成员之间在自测保障上通常聚焦自身所做的功能，兼顾整体上是有点困难的。功能混杂或需求合并开发不仅仅会造成版本迭代慢、项目周转不灵活，更容易滋生风险，一旦出现需求变更，牵动整个版本的进度；同时测试完成一个大而全版本的测试，首轮测试花费的测试反馈周期也比较长。
b、测试优势发挥；在面临这样的情况下，测试可以从自身职能中适当跳出来，充分调动我们测试对全局性业务理解的优势，去帮助引导产品同学。比如放弃或减少那些覆盖用户密度少、使用频次低、使用强度弱的需求。理性面对需求合理性，对拆分不清的需求或大而模糊的需求勇于表达否定意见，并协同研发推进产品对需求降解。降解之后的需求，对研发人力调度，整体交付也更加灵活了。需求降解解耦后，我们有时还需要考虑版本的切割引导。通过切割引导让测试侧的处理更加灵活；比如可以考虑把若干个小需求集合在一个版本进行提测，同时若交付的版本较大，可以评估是否可以进行过程划分多个版本提测。在保障满足业务需要的前提下，对如何发版如何规划版本给予合理的评估意见参考；
c、小步快跑加速；通过需求的降解和版本大小的规划参与，加速小步快跑的交付；这里也要说一下交付内容具有业务层面可测试性，即需求版本的合理划分，无论多小的交付，都必须能实现一个完整的业务场景。

4、通过缺陷复盘回顾机制，解决研测阶段缺陷价值重视不足的问题，通过缺陷引入根因的严格填写总结和阶段缺陷的持续学习，重视缺陷的反哺作用，打造完整价值闭环。
以下呈现我们的实践步骤：
a、缺陷起因追溯；实现缺陷引入的根因定位，需要推进研发对缺陷起因认真书写对待，拒绝随意填写，针对随意填写进行打回处理；缺陷起因是研发针对缺陷引入原因的进一步强化认知，若仅是三个字“已修复”，不仅浪费了强化认知的机会，同时也让测试同学对缺陷引入不知所以然。更重要的是，到了缺陷复盘回顾的时候，自己去解读缺陷的时候，不知道缺陷咋回事了。
b、缺陷多维分析；每月形成有力的缺陷多维分析报告，通过报告让研发内部对版本质量水平和各成员贡献程度有清晰的了解，从研发内部形成压力提升组员质量意识。同时针对性的分析，尽可能透过偶然性，去发现必然性，来找出下一阶段的避免缺陷方法，在实际复盘时进行讨论。
c、月度缺陷复盘；在前两个措施都落地的情况下，每月研测同学对所在方向的缺陷进行会议复盘，复盘时由缺陷引入者讲解自身引入的缺陷，通过复盘讨论客观的追踪问题本身，形成可落地的执行方案。有负面案例积极复盘，当然我们更支持优秀案例的复盘传递经验。

5、通过需求问题归档复盘，实现需求问题的高效管理流转，通过阶段性的抽取典型需求问题进行产研测整体复盘，实现需求问题的良性反哺，不断优化初始质量建设。
以下呈现我们的实践步骤：
a、交付团队内部共识；这是一块敏感的实践，相当于把产品的问题记录在案，在案之后并阶段性的集体复盘，这一块落地对产品侧的压力还是有的，所以需要产品侧包容性的看待这项工作的价值，所以需要交付团队内部形成共识，并认知归档的意义，需求问题的价值类同研测阶段缺陷的价值，需求问题常态下对工期进度风险的影响不亚于研测阶段缺陷，比如最开始的bug图所体现的那样，后面是滚雪球。此项工作开展于版本交付测试前，研测一同参与。
b、优化问题管理流程；作为一个产研测都会参与流程流转，所以对流程效率和易用性也有要求，为满足归档的要求，我们对问题管理流程进行了优化，实现需求问题与原始需求的直接挂载链接（我们在查看对应需求时，也可以快速的获知需求历史过程中所提的需求问题），实现新增需求问题识别阶段标识，形成需求问题专属看板。
c、阶段典型问题复盘；归档之后的问题同样也会根据需要阶段性组织复盘，若归档的问题比较多，就需要研测同学共同商榷抽取典型需求问题，产研测三方复盘，由产品侧给出务实改进措施，形成良性反哺。

学习资源推荐
《完美软件：缺陷预防最佳实践》或者通过缺陷预防/测试左移/质量内建等关键词网络搜索寻找获取相关实践案例，重点推荐关注TOP100历届的测试实践专场的PPT案例材料

作业思考题
以下哪些措施的落地可以实现缺陷预防能力的建设？
A：版本质量度量体系，提升研发的质量意识
B：缺陷复盘回顾机制，重视缺陷的反哺价值
C：需求问题归档复盘，引导产品初始质量建设
D：需求解耦版本切割，降低研发测试交付难度
答案：A、B、C、D