“写 Bug 的时间” vs 修 Bug 的时间

有一阵子没有写团队实践的文章了，今天参加了一个团队的 sprint review 会议。有一些有意思的发现，想和大家分享一下。

2 周一次的迭代，今天是最后一天，下午 4:00 到 5:00，团队向 PO 演示了本次开发的功能。在最后演示结束的时候，QA Lead 感叹了这次迭代中一个有趣的现象：

1. 一个本来复杂的功能（开发 2 天），觉得 bug 会很多。但是实际交付之后无 bug。

2. 一个本来简单的功能（开发半天），觉得 bug 会很少。实际交付后，断断续续持续了 3 天，开发一直在改动。

这让我不由得好奇起来，会后的回顾会上。和 Team 一起探究了一下原因：

• 复杂的功能开发很重视，所以第一时间编写了测试用例。在开发过程中一直保持测试。尽可能覆盖所有 case。于是在交付的时候，发现问题很少。

• 简单的功能开发的时候，开发人员觉得简单，同时不知道如何对 controller 进行测试编写，就没有编写测试，单纯编写功能代码，导致本应改动的地方遗漏，带来了很多问题。

这个现象让我想起了以往一直在争论的“写 Bug”和修 Bug，哪个更浪费时间？看下图，一个很经典的统计图：

• 你会发现蓝色线条是注入 bug 的时间和数量。没错，就是开发编写代码的时候。有一句话说得好，每一个 bug 都是开发认认真真地写进去的，而不是 QA 测出来的哦。

• 黄色线是 bug 被发现的数量和相应的阶段。可以看到在功能测试和集成测试阶段最多。

• 红色线是修复 bug 的成本。你会发现越晚发现越贵。

团队还有一个洞察：在开发功能的同时编写测试，比单纯开发功能要多 20%～30%的工作量。但是交付质量更高，带来的好处是节省了修改 bug 的时间，用这次迭代修改那个简单功能的 bug 来看，3 天修改 bug 的时间来远远大于写测试那多出来的 30%的工作量。

总结

“写 bug“还是修 bug，哪个更浪费时间？相信你应该有结论了。这里给”写 bug“加了引号，其实是自嘲一下，开发写功能的时候不就是 bug 被注入的阶段吗？无论从图表还是团队实践都能感受到。测试左移的重要性。写测试花费的时间是值得的，不要舍不得哦。

践行敏捷实践，让工作变得更美好。欢迎关注我的公众号，交流落地经验。

【欢迎关注我的个人博客】