首先提出一个问题：

如果在探索性测试阶段发现很多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测试时候的测试能力也是很高的。现在我还有一些其他的想法，这里就不展开说了。）

如果在之前阶段都做的很好，是否到探索性测试阶段，就不会发现Bug了