Bug改不完，迭代总延期，咋办？( 二 ) _生活百科

测试上，没有能力做到持续回归测试新功能测试完毕后，要进行回归测试，这时候发现出现很多已有功能的Bug 。已有功能的Bug又是新功能代码间接引入的，查找问题原因，修复Bug ，再针对这一次修复进行回归，流程很长，花费时间比修复新功能的Bug要多。由于回归测试常常是放在了测试环节里面的最后一步来做，时间盒已经消耗殆?。斐傻悠?。
传统项目里，回归测试常常做好几轮。以一个三个月开发周期为例，第四个月开始测试工作，到了月底可能测试+修复的差不多了，进行第一轮回归测试，然后继续修复新发现的Bug 。一周后进行第二轮回归测试，再修复新Bug，再3天后进行第三轮回归测试，再修复，这样的流程。
我们都知道做软件开发过程中，会带来很多已有功能的Bug，但是依旧选择将这么重要的回归测试放在了项目的最最最后的那几天，导致集中出现大量的已有功能的Bug 。通常这都是由于，做一次回归测试需要的时间太久导致的，团队没有能力做到每次更改代码，都快速的做一遍全量回归测试。
解决措施针对上面提出的导致因为修复不完Bug而延期的四个方面问题，给出以下建议。
流程上，避免小瀑布陷阱一定要避免诸如前半周需求，后半周设计，第一周开发第二周测试这样的小瀑布开发模式。
无论迭代里有多少个需求，一个迭代时长是几周，每开发完一个需求，立刻开始测试工作。
理想状态如下：
? 第一个需求开发完毕，测试人员开始测试，开发开始为第二个需求进行编码，期间同时修复第一个需求的Bug 。
? 等第二个需求开发完毕，第一个需求的测试及bug修复应该也结束了，然后第三个需求的开发和第二个需求的测试工作应该开始了。
如果团队使用Scrum框架的话，那么在每天的站立会议上，团队在看板上移动需求卡片时，测试人员关注那些已经被开发人员移动到了已解决的卡片，按照实际能力将相应数量的移动到测试中，如下图所示。

文章插图
图3 合理的任务看板
上图中，进行中和测试中的卡片数量都看上去没那么多，比较合理。如果出现类似下面的情况，开发活动开始了，完成了好多需求，但是测试活动远远落后，就要注意了，你可能掉进了小瀑布陷阱。

文章插图
图4 不合理的任务看板
按照【图3：合理的任务看板】的卡片流转情况，这样可以尽早的发现需求的缺陷，降低了缺陷在系统中存留的时间，就是降低了它带来的风险。
需求上，澄清需求的时候明确验收标准在需求澄清的时候，团队和产品负责人要对验收标准达成一致意见，并且记录下来，以辅助开发团队编码时有法可依。下图为示意图，在DevCloud记录用户故事的工作项里，同时记录验收标准，减少最后验收时出现需求式的Bug 。

文章插图
图5 DevCloud用户故事中的验收标准
质量上，通过预防来产生质量质量管理大师克劳士比的质量管理基本原则里提到，预防产生质量，检验不能产生质量。所以，如果我们能在开发的时候就采取预防措施，做到第一次做正确，这才产生了质量，这也是零缺陷管理的核心。

文章插图
图6 克劳士比零缺陷管理三要素
根据我们的实践和总结，推荐如下动作：
1. 沟通需求的时候，团队一起了解需求，在用户故事卡片里帮助添加检查点，以便于在编码的时候就会提前考虑这些检查点，进而编写代码的同时就保证了质量。
2. 在讨论需求和设计的时候，团队（一般由架构师或者技术能力强的测试人员来主导）就针对当前的设计和使用的技术提出需要注意的问题和建议，可以让开发人员在编码的时候就规避了潜在质量问题。
通过以上活动，从产品内在提高了质量，可以从本身上大大减少Bug数量。
测试上，加强自动化测试做到持续回归从迭代里的第一次提交代码开始，任何一次提交代码，都做一次回归测试，这样可以保证第一时间发现对已有功能的影响，尽早修复，而不是在最后一次回归测试的时候发现问题。这个回归测试速度要快，也就是不花费太多时间，同时覆盖的面越广越好。