有一阵子没有写团队实践的文章了，今天参加了一个团队的sprint review会议。有一些有意思的发现，想和大家分享一下。
2周一次的迭代，今天是最后一天，下午4:00到5:00，团队向PO演示了本次开发的功能。在最后演示结束的时候，QA Lead感叹了这次迭代中一个有趣的现象：
- 一个本来复杂的功能（开发2天），觉得bug会很多。但是实际交付之后无bug。
- 一个本来简单的功能（开发半天），觉得bug会很少。实际交付后，断断续续持续了3天，开发一直在改动。
这让我不由得好奇起来，会后的回顾会上。和Team一起探究了一下原因：
- 复杂的功能开发很重视，所以第一时间编写了测试用例。在开发过程中一直保持测试。尽可能覆盖所有case。于是在交付的时候，发现问题很少。
- 简单的功能开发的时候，开发人员觉得简单，同时不知道如何对controller进行测试编写，就没有编写测试，单纯编写功能代码，导致本应改动的地方遗漏，带来了很多问题。
这个现象让我想起了以往一直在争论的“写Bug”和修Bug，哪个更浪费时间？看下图，一个很经典的统计图：
- 你会发现蓝色线条是注入bug的时间和数量。没错，就是开发编写代码的时候。有一句话说得好，每一个bug都是开发认认真真地写进去的，而不是QA测出来的哦。
- 黄色线是bug被发现的数量和相应的阶段。可以看到在功能测试和集成测试阶段最多。
- 红色线是修复bug的成本。你会发现越晚发现越贵。
团队还有一个洞察：在开发功能的同时编写测试，比单纯开发功能要多20%～30%的工作量。但是交付质量更高，带来的好处是节省了修改bug的时间，用这次迭代修改那个简单功能的bug来看，3天修改bug的时间来远远大于写测试那多出来的30%的工作量。
总结
“写bug“还是修bug，哪个更浪费时间？相信你应该有结论了。这里给”写bug“加了引号，其实是自嘲一下，开发写功能的时候不就是bug被注入的阶段吗？无论从图表还是团队实践都能感受到。测试左移的重要性。写测试花费的时间是值得的，不要舍不得哦。
践行敏捷实践，让工作变得更美好。欢迎关注我的公众号，交流落地经验。
