谬论：一个测试人员的唯一任务就是找到程序缺陷。

    事实：关于测试人员的作用的这个观点是非常有局限性的，并且对于客户没有增加价值。测试人员都是被测试系统，应用软件或产品的专家。不象负责一个特殊功能或组件的开发人员，测试人员懂得系统作为一个整体是如何工作的来达到客户的目标。测试人员懂得由产品增加的价值，关于产品效率的环境的影响，以及从产品得到最多输出的最好方法。

    通过这个产品知识扩展了我们测试人员的价值和作用。扩展测试人员的作用（诸如技巧，技术，指导方针，以及为使用而进行的非常好的练习）最终减少了客户所有权的成本和增加了测试人员的商业价值。

    谬论：我们没有足够的资源和时间来全面测试产品。

    事实：你不需要全面测试产品——你需要充分测试产品来减少一个客户将被消极地影响的风险。

    变化市场的事实通常要求在给定的时间框架中详尽地测试一个产品，但事实上是不可能的。这就是我们需要测试的一个实用方法的原因。关注于你的客户的商业过程来确定你的测试优先级。联合系统的内部客户来测试你的产品。当提供真实世界可用性的反馈时，这些步骤增加了你的测试资源。同时你也可以在一个外部客户实验室中来做你的系统测试，来增长你的真实世界环境的经验而不用增加你的维护或系统管理活动。

    谬论：测试应当发生在一个被控制的环境中。

    事实：测试环境越象最终产品环境，测试越可靠。如果客户环境被严格控制，那么你可以在一个被控制的环境中做你所有的测试。但是如果最终产品环境没有被控制，那么你在一个被控制的环境中做你测试的100%的工作将会使你错过一些重要的情况。

    尽管难以预测的事件和不同的环境难以效仿，但它们是十分常见的，因此也是值得期待的。在我们当前的全球市场能够中，你的应用软件将被用于灵活的，分布的，和多变的情况是十分可能的。在迭代测试中，我们因此根据处于不同环境中的客户来同时确定商业使用模型检查和系统测试活动的时间进度。早期的商业使用检查确定目标客户市场的差异性，优先于编码。在客户现场进行系统测试是在真实世界中运用了我们的产品。尽管产品的这些“预发布”版本仍然在我们开发人员的手中，并运行于我们的工作站上，但它们已经在客户真实世界的办公室（或实验室）的环境和应用软件中被测试。尽管这个策略不能覆盖每一个可能性，但它承认不可预知性的存在。

    谬论：所有的客户有着同等的重要性。

    事实：一些客户要比其他客户更加重要，这是基于一个特殊发布的目标。例如，如果一月发布的发布定义特性是将传统MyWidget数据转变为MyPalmPilot的特性，那么我们的用户使用MyWidget和MyPalmPilot的反应对于这个特殊的发布来说，要比其他客户的输入更加重要。

    所有我们的客户当然都是重要的。但是迭代测试的目标是关注于这个特殊迭代法的最重要特性。如果我们正在将特性XYZ输送到这个迭代法中，我们需要来自于熟悉优先的XYZ功能的使用者的专家对XYZ的评价。就象我们欢迎其它反馈一样，诸如新使用者的印象，XYZ特性的优先考虑。在开发的这个阶段，刚刚接触市场的使用者不能帮助我们设计“正确的XYZ特性”。

    谬论：如果我们正在寻找很多程序缺陷，我们正在做重要的测试。

    事实：找到很多程序缺陷的唯一好处就是告诉我们产品存在很多程序缺陷。它没有告诉我们测试覆盖的质量，程序缺陷的严重性，或是客户将在实际中碰到它们的频率。同样它也没有告诉我们遗留下多少程序缺陷。

    停止找到程序缺陷的唯一确定方法就是停止测试。它看起来是荒谬的，但这个想法是有价值的。这个难题的症结在于指出产品的什么特性确实需要研究。我已经提到产品中的许多工作流实际没有被使用——并且如果它们没有被使用，它们就不需要被研究。直接在你的测试计划中合并客户使用知识以及缺点筛余机制提高了你预测客户影响和与缺点相关的风险概率。在你的测试计划解决中合并基于风险和客户分析将产生一个更加实际和实用的测试计划。一旦你对你的测试计划有信心，你可以在你已经执行计划之后停止测试。

    你如何建立那种信心？开始你的测试计划时要确定你需要测试的所有区域。让客户检查和评价商业过程并使用实例以便你懂得每一个被提议的测试实例的频率和重要性。要特别注意检查测试漏洞。对每一个迭代要持续更新和检查你的测试计划和测试实例。你的目标是找到什么没有被覆盖到。做到这个的一种方法是通过软件区域和测试种类来映射程序缺陷计数。如果一个软件区域没有被记录缺点，它可能意味着这个区域是十分有效的或者它还没有被测试。看缺陷文件的时间戳。如果最后的缺陷是去年公布的，可能它暂时不用被测试。找到错过的程序错误的模式是检查测试覆盖的一个重要技术。

    谬论：完全的测试意味着测试 100% 的需求。

    事实：测试需求是重要的，但是不是充分的。你还需要测试那些遗漏的事情。有什么重要需求的没有被列出？

    找到没有被列出的是一个有趣的挑战。 迭代测试很早就使客户客户参与进来。客户懂得他们的业务如何进行和他们如何工作。他们可以告诉你你的应用软件中错过了什么，并且提出什么妨碍了他们需要完成的任务。

    谬论：它是一个间歇的程序错误。

    事实：不存在间歇的程序错误。问题是一直存在的——你只是没有指出正确的条件来复制它。提供可用的工具来持续监控执行，应用软件降级开始的自动校准，以及在降级的时候自动发出适当的数据（优先于应用软件实际崩溃）减少内部故障诊断时间和客户停工时间。迭代测试和迭代可用性活动都可以减少没有被发现的程序错误对商业的影响。

    更加实用和好用的诊断程序增加了你的产品的客户价值。当你的产品开始升级时，通过前摄的监控环境，你可以减少分析时间甚至可以避免由于开始各种自动更正校准和工作区的例行程序而导致的停工。自治服务例行程序的这些类型增加了你的产品的可靠性，耐久性，和运行持续时间，甚至如果程序缺陷复制品的条件是未知的。

    在某种意义上，自治的恢复例行程序提供了一个标准的持续的技术支持。环境记录和处理跟踪信息被自动收集并被发送，以用于更进一步缺点分析的开发，同时也提供了关于你的产品是如何被实际使用的重要数据。

    如果我们承认程序缺陷是不可避免的，我们同样需要认识到适当有用的例行程序的重要性。这些自诊断和自行监控功能在增加客户价值和满意度中是有效的，因为它们减少了客户受程序缺陷消极影响的风险。然而即使这些例行程序增加了客户价值，只有少数几个开发周期被用于将这些过程归位。

    谬论：产品应当在压力下被测试以验证性能、可伸缩性和耐久性。

    事实：上面是正确的。但它的反面也是正确的。使一个应用软件保持在空闲，或长期处于暂停的状态来仿效客户去吃午饭或使应用软件在周末暂停，并经常暴露一些问题。

    我推荐在你的功能测试方法中包括睡觉，暂停，中止，中断和睡眠状态恢复。仿效一个地理分布式工作环境，当你的应用软件处于中止或暂停状态，而其中的共享工件和数据库正在变化（正如同事们在其他人的业余时间在一个偏僻的地点工作）。测试当使用者“唤醒它”时发生了什么，这与他们被挂起的环境是不同的。然而更好的是将你的产品放到一个真实的客户环境中并运行仿效上面的一些场景的系统测试。