这个测试项目记录了包括重复在内的：200个偏差。大约有150个偏差报告给了开发人员，其中65个被接受，剩下的偏差不得不推迟到“下一个版本”，因此系统必须变成功能有限的产品——推迟了3个月。因此项目小组把测试看作是成功的。我们没让一个有太多“故障”的系统变成产品而把问题留给客户。

　　我们在前面提到的类比意思是说每个人在某个时候或其他时候都用过某种形式的探索性或双人组技术。但是要把事情做对需要一定的技巧。那么它需要什么技巧?我们获得了什么样的有用经验呢?

　　有些人会说什么也没有，他们会争辩说这个项目太小了，而且太“紧迫”。我们很少有时间为双人组做准备。我们并没有一个定义好的、能衡量覆盖率的方法。我们把探索性技术当作一条“出路”，因为我们并没有足够的信息来用传统的测试脚本a因此从这个项目中并不能够得出结论。

　　其他一些人说我们确实学到了很多：探索性测试、双人测试和管理高速的缺乏文档的web项目。很不幸，这种情况出现得比较频繁，因为上市时间是所有客户都关心的问题。这也是我们第一次尝试测试的一种概念，在这个测试中，双人组和探索性技术被“正式化，’了，不仅仅是项目的附属，或临时的测试方法。在很多方面它给予我们的比我们想要的还要多。

　　就像James Bach陈述的那样，在进行探索性测试的时候，测试人员需要提前进行探索性测试的。r培训”。幸运的是，我们的测试人员在测试之前就已经完成了为期两天的学习指导课程。为了确保尽可能全面，在第一天我们还或多或少地进行了正式的功能性测试。这不仅使测试人员对软件有了更好的理解，而且还向他们指出了系统中错误可能发生的地方。这是很重要的，因为探索性测试就是使用您所知道的东西。确实会出现的一个问题是当在软件的一小部分中发现错误的时候，所有的双人组都开始检查那个部分。由于双人组没有进行过探索性测试的培训，因此我们需要在不同的方向上指引他们以提高测试的覆盖率。也许在计划阶段就应该考虑到这个问题。

　　同事提出了许多问题，他们不知道我们如何控制这样一个非结构化的测试。在发现“故障”的时候，我们如何保证填写了偏差报告?如何能知道测试人员是否坚持了测试计划?如何确保他们是完全具有工作能力的?我们是否会不断地在房间里转来转去?我们不是在一个房间里转，而是在三个不同的房间里“跑”(因为我们把Windows 95、2000和NT放在不同的房间里了)。困难的事情不是让测试人员进行测试，而是让他们不要测试计划以外的内容。当我们在几个房间里穿梭的时候，我们脑子里会得到一幅测试人员工作的画面(只有14个人，因此并不那么令人疲惫不堪)。只要我们看到有一组没有在计划区域内工作或是出现了别人已经报告过的错误，我们一般会给他们一些小的暗示。比如“您试过这个了吗”或“如果您那样做会发生什么?”为了使每个人都不脱离。r正轨”，我们这样做就可以了。在分组工作时，其中一个测试人员总是负责填写偏差报表。这是一个很容易填写的表，但是使故障重现已经足够了。在每

　　个暂停阶段(在每次90分钟的测试后)，如果可能的话我们与项目经理一起通读所有的. 报告，以确保我们理解所记录的东西以及确保我们有足够的信息来重现故障。此外在每个暂停阶段，我们常与所有人交流并且一天三次地把所有人聚集到一个房间里

　　我们运气不错.碰上了这些双人组。通常，我们应该提前了解测试人员，并且具有一点“人文知识，，才能使分组得当。但我们没有时间做这个，因此我们依据职业(在一个双人组中不要两个都是开发人员)、国籍(为了增进交流)和他们自己的意愿去分组。这样做相当不错。但是我们也有过两天后双人组就需要改变的经历。这是容易和快速的，而且后来所有事情都进行得很顺利。这也许是一个明智的办法，在您找到高效的合作伙伴之前，您经常会不得不去“试验”测试人员。

　　对使用探索性双人测试来说，其中一个挑战是确保测试执行过程中功能性的覆盖章。双人组的跟踪检查需要广泛的资源和来自测试管理者的实际管理。更加合适的测试管理工具和测试技术可能会解决这个问题。我们知道很少的工具能支持这种测试计划和执行，但是现在一种称为“以测试会话为基础的测试管理”的技术已经开发出来’这是解决衡量覆盖率和在不破坏创造性的情况下提高效率的方法【BACH01]。

　　在寻找故障的过程中，我们确实发现了很多偏差和故障，但是其中很多是重复的。我们让测试人员对整个系统进行无秩序的搜寻，很多双人组发现了相同的故障。下一次我们将让每个双人组关注一个特定的部分。过一段时间·我们将把双人组和测试部分进行交换.