使用面向业务的例子来设计产品是好的，但是假设例子是错误的怎么办？谁都会犯错误。业务专家会忘记一些用户真正需要的东西。或者业务专家错误地表达了需求，而程序员却非常忠诚地实现了错误的东西。
那些错误，如果记起来了或注意到了，则可能会当作bug，也可能被认为是需要的功能特性。但两者的界限很模糊。我会简单地把它们叫做“问题”。
问题是如何引起项目组的注意的呢？
很多敏捷项目组会在一个迭代结束时向业务专家和感兴趣的外部人员演示软件系统。这时候会是激怒某个人的时候，“噢…我是那样说过，但是我不是这个意思”。
敏捷项目喜欢频繁地发布软件给它的用户（可能比用户希望更新的频率还要频繁）。当用户试用产品的时候，他们会指出存在的问题。
这些反馈循环很紧凑，比传统的项目要紧密，因为敏捷项目喜欢短的迭代。但是它们不是最理想的。业务专家可能由于过于靠近项目而不能以新的、没有偏见的眼光去发现问题。用户通常不报告他们在软件使用中发现的问题。当他们反馈问题时，报告得又不够专业以致没办法执行。而反馈的周期不能像敏捷项目希望的那样的频繁。可能仅仅是针对一行代码的改变的反馈，但是需要等上3个月才能从用户那收集到。
因此，我们需要额外的产品批判形式 – 能注意到用户会怎样，而且能及时注意到。
产品批判的方式拥有前期创建的例子所不具备的资源：一个新的迭代版本的真正工作的软件。当你描述某些目前不存在的东西的时候，你是在脑海里操作一个抽象的东西，一个你想象中的物品。当你亲手操作一个产品的时候会激发不同的理解和判断。你可能注意到，当试驾一辆汽车的时候，你不会专注于它的规格说明。操纵是与思考不一样的。
因此，面向业务的产品批判应该专注于操作方面，尝试逼近真正的不同用户的体验。就像James Bach，Cem Kaner，Elisabeth Hendrickson他们所说的探索性测试（Exploratory）的形式。
进一步的，我发现我们在尝试至少5种类型的探索性测试：
1、 一个探索性测试员
2、 结对探索性测试员。James Bach 和Cem Kaner可能在这方面有最多的经验。
3、 探索性测试员与一个程序员结对。Jonathan Kohl会在2004年1月的STQE杂志（http://www.stqemagazine.com/）有一篇这样的文章。我在这方面没有什么经验，程序员也喜欢这样的方式。值得注意的是，当我在RoleModel Software进行这种方式的时候，它导致了一个有趣的并且有用的关于基础程序的讨论。那样的话，它成了一种类似回顾的方式，这进一步让我相信它是迭代结束时很好的一种活动。
4、 让探索性测试员与项目中的业务专家结对
5、 让探索性测试员与感兴趣的非参与者（用SCRUM的术语来说就是“chickens，小鸡”），例如经理主管、新用户等等。
对于每一种，我们应该探索关于什么时候测试员应该是项目组外的人的问题。这些外部的测试人员不会存在偏见和先入为主，但是存在缺点就是：他们需要花更多的时间来学习一些基本的东西。那也会使发现的问题存在一些偏离。
当我一年前开始在敏捷项目谈论探索性测试的时候，我想它会在发现bug的同时对提出一些大胆的关于产品的新构思有启迪作用。一个过程能发现两类问题。有一段时间，我把它叫做“探索性学习”来强调它的扩展的角色。
后来我推断这两个目标不能很好地走在一起。因为找bug实在是太诱人了 – 对于功能特性的思考会在探索性测试的过程中迷失。有些时候能同时出现，但是不足够。所以我想可能需要一个单独的功能特性的脑力风暴活动。关于这一点，现在我还没有什么特别好的主意。“需要进一步的研究”。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/