首先提出一个问题：

如果在探索性测试阶段发现很多 bug，这是否是由于之前卡中 AC 写的不够详尽？或者是开卡时候 QA、开发、BA 等人一起讨论的不够深入？我换一个问题，如果在之前阶段都做的很好，到探索性测试阶段，是否就不会发现 Bug 了？

对于这个问题，我的想法是：

在一个开发团队里有十多个人，大家都使用同样的研发流程，在每张卡中的 AC 也尽量写的详尽，但是你可以看到，大约 10 年开发经验的人和 2，3 年开发经验的人最后测出的 Bug 数差别很大。我的问题是，为什么同样的流程，类似的卡的 AC 描述详细程度，对于开发年限的不同，会出现的 bug 数不同？

实际上从人的角度来看，对于同样的一段话不同的人会有不同的理解，10 年经验和 3 年经验的理解会有不同，这些不同是可能包括开发多年来对软件架构的认识，对代码最佳实践的认识等等。如果我们想在 AC 中帮助 3 年经验的人去注意到所有的这些点，不是不可能，但是要在卡上写的注释太多了，这个数量多到在真实工作中难以完成的地步，举个例子，一个登录场景的测试脑图，其中覆盖点就有四五十个之多。即使我们把这四五十个测试点都写入卡中，测试要花多少时间写卡，开发要花多少时间记忆？另外，作为 QA 拿到一个新功能，也未必能想全所有的场景，这就因为下面第二个问题。

其次第二个问题，我们 QA 自己在卡 kick off 时候也不一定想全各种场景，因为这时候没有软件系统，缺少系统的各种反馈。QA 也需要接触到系统后，通过各种输入，观察系统的输出，然后预测那些点可能会出现缺陷，然后继续深入给出特定的输入，观察有无 bug。

因此，我们可以做的是在测试之前的各个环节做 QA 工作的输出，尽量去避免一些 Bug，但是还需要做详细的探索性测试，去验证系统是否没有 bug。

（最后有个题外话，其实，如果能帮助整个开发团队提高自测能力，是减少 Bug 非常有效的方法。我的做法是最早写了一些测试 Blog，在 session 时候和大家一起探讨，后来又和开发一起 pair 测试，你会发现开发和你 pair 测试时候的测试能力也是很高的。现在我还有一些其他的想法，这里就不展开说了。）