怎么控制Free testing/ad-hoc testing

[51每周一问]http://bbs.51testing.com/viewthread.php?tid=251383&page=1#pid1598650

Free testing/ad-hoc testing/exploratory testing是一种基于测试人员自觉性、测试人员个体经验的测试，经常看到很多测试人员碰到这种测试就是随便玩玩，比如看看网页，很少或者根本没有测试人员去尽量的发现Bug。作为测试组的负责人，怎么控制Free testing/ad-hoc testing/exploratory testing及其质量呢？

我的观点：

Exploratory testing是与scripted testing相对应的概念，强调test case design和execution不是严格顺序关系，而是tester在边测试边学习的过程中，通过对被测系统的不断学习和了解来对test case design 和execution进行不断优化，达到更有效地测试的目的。必须强调的是exploratory testing是在一定框架指导下的适当发挥自由的测试，而非毫无目的瞎撞，希望瞎猫能逮到死耗子。而ad-hoc testing 更随意些，更多的时候是天马行空突发奇想。这类测试因为不特别强调事先的准备或者说文档，而有点骑驴看唱本的味道，与传统的按照test case执行测试相比，其完成情况比较难度量。

“作为测试组的负责人，怎么控制Free testing/ad-hoc testing/exploratory testing及其质量呢？”其实测试有效性不是组长控制出来。不能通过这种原本应该很有效的测试方法发现足够多的bug，可能最大的原因是不了解这种技能，因此不能正确地使用它。所以作为测试组的负责人首先要帮助组员掌握exploratory testing/ad-hoc testing相关的技能：消除ad-hoc testing就是随便点点的误解，并了解从哪些大的方面去考虑，才可能在看似无意的测试中找到有价值的缺陷，如数据的多样性、操作步骤的顺序、对空值的判断、特殊字符的处理、环境的差异等等。其次可以通过经常的bug sharing（包括对于一些奇怪的bug的根本原因的分析）在组内帮助大家集思广益，互相启发，互相学习，从而发现更多的潜在（而非严格与需求相关）的bug。另外，更多地了解用户的使用习惯，更多地了解产品架构、技术、设计甚至编码也能帮助启发tester想到可能出现的bug。组员掌握了基本技能后，通过长期的经验积累、敏锐的洞察力、丰富的想象力可以进一步提升测试的有效性，从而达到武林高手的境界：手中无剑，心中有剑。即便不按照写好的test case出招，也能手到擒来，快速找到有价值的隐藏又比较深的缺陷。每个组员都具备了这种能力，组长就无需控制了。*_*