谬论：软件开发和测试的需求需要很稳定并且尽早的定义好，这样才最有效率。

    事实：如果我们最终的目标是“有效率的软件开发和测试”，那么稳定和定义良好的需求在最开始是必须的。但是我们实际的目标是生产一个客户承认的产品。我们大部分人都承认我们往往不知道什么才满足客户需求的。因为在现今的市场情况下，需求是经常变化的，例如新的产品和选择，我们经常要在被介绍新概念和信息之后改变我们的主意。如果你承认上面的情况，那么一个主要的原因就是为什么我们不能有效地保证需求的稳定性。在开发过程中频繁的和产品交互会不断暴露客户的需求，使得我们变更我们的过程来更好的达到客户的变化需求和价值。

    谬论：当代码设计的时间超过了时间表的计划，降低测试的时间可以帮助我们重新回到时间表的计划上。

    事实：一般情况代码设计的延误是由于未预料到的困难或者没有按照最开始的设计工作。当我们发现我们低估了项目的复杂性的时候，缩短测试时间是一个糟糕的决定。相反，我们应该保证测试的执行，因为测试的结果是建立在我们低估代码设计的情况上的，测试的效果或许也会被低估。因此我们需要定制更多的测试时间来更正开始的判断，而不是减少测试时间。

    迭代测试增加了测试时间但是并没有延误整个的时间进度，因为在每一个迭代过程中测试过程都是提前开始的。同样，产品的质量决定了需要测试的数量——而不是由时间决定的。例如，如果产品是可靠的，在很多领域都没有发现缺陷，并且测试进行的十分顺利，那么你可以在保证测试数量和测试覆盖率的前提下降低测试的时间。如果产品不够稳定，发现了很多缺陷，那么你需要增加测试的周期直到达到质量标准。请记住，测试并不是项目最耗时的工作。

    谬论：找到并修正所有的缺陷将会建立一个高质量的产品。

    事实：近来的研究显示，只有10%软件开发活动，例如建立客户需求特性，能够实际增加客户的价值。开发过程中加入一定比例的特性能够增加产品在市场中的竞争力，但是它们往往不是客户要求或者期望的。查找和修正这些缺陷不会增加客户的价值，因为客户可能永远也不会遇到这类的错误。

    从另一个角度讲，迭代测试实际上会减少缺陷的数量和客户等待的时间，当然这是基于客户价值考虑的。在迭代过程中引入客户意见，迭代测试压缩对客户的交付周期，从而最大化应用程序对于这个客户的价值。

    谬论：不断的回归测试每一件我们更改的代码是十分冗余和费时的工作，只有在理想化的世界中才会这么做。

    事实：回归测试并不意味着“每次测试每件事”。

    迭代回归测试的意思是测试每个阶段中敏感的部分。它也意味着基于改动效果，产品历史和早期测试结果而更改我们的测试覆盖率。

    如果你的回归测试是自动执行的，那么你可以在同时运行所有测试。如果不是，那么请选择你想要完成测试的部分进行测试。例如，你可以在“验收”产品之前之前运行一个“完整的回归套件”或者“一系列验收测试”f。由于每一个回归过程都不是必须相同的，测试不需要每一次都相同。把精力集中在特性和测试上面对于即将到来的交付阶段是十分有意义的。例如，如果你使用第三方的组件，比如一个承包商或者开源的产品，完整的回归套件将会把焦点集中在外部和内部组件的集合点上。如果在你初始化第三方模块完整回归测试时，发现了缺陷或者回归，那么你可以选择添加基于早期结果的额外测试来改变你的回归套件。

    换句话说，如果你在你的控制之下在整个产品开发中进行一系列的缺陷修复工作，那么完整的回归套件应该被完全聚焦并构建在你的端到端，高概括的客户用例上。如果更改被限制在一个领域，并且产品拥有一个稳定的质量追踪记录，那么你可以把精力全部集中在这个回归套件中。同样，在最后阶段，你或许需要一个非常小的能够覆盖介质安装的完整回归套件，但并不是深层次的或者端到端的测试。完整或者验收回归套件的重点依赖于在前一个周期测试了什么，产品的一般稳定性和下一个迭代的重点。

    谬论：这不是一个缺陷——特性随着设计而出现。

    事实：过多的解释为什么产品会做它现在正在做的事情是一个普遍的陷阱。有时候我们知道的太多了。当缺陷被修复和评审的时候，我们经常为缺陷自圆其说。有时候我们把缺陷标志成为“伴随设计更正”或者“不计划修复”，因为应用程序实际上是伴随着设计工作的，更改设计将是过于昂贵和具有风险的。同样的，我们解释了很多关于“它是一个外部组件”或者“它是一个钟表或者汽笛”的可用性。我们的窗口小部件或者 UI 控件将会受到限制。或者我们告诉我们自己“一旦用户知道要这么做，他们将会很好”。

    总而言之：我们了解了代码的输入和输出，以及他们为什么这么工作。在这个部件层次上，我们做了非常合理和明智的决定。但是我们缺少对整个客户经验的整体观。我们没有给我们编码平衡和工作区带来最终效果增值。我们的主要聚焦点是使重要的代码按时完成。通过聚焦于个别的特性或者组件，我们不经意的做了一些代码的决定，这对产品的全面流程和可用性产生了消极的影响。毕竟，最大限度影响客户效率的是可用性。而驱使用户放弃一定数量功能的也是可用性。

    超过上面的细节层次提升我们对于项目的见解，会允许我们以客户期待的视角看待我们的产品——通过全局的层面，而不是单个的组件。这种提高后的视角帮助我们忽略了对于产品为什么这么工作的所有原因的探究。客户不会关心给定的设计是否会加快代码的设计。对于客户来说用户界面是否与你特定开发任务外的组件X的API冲突与他们无关。他们只关心这个产品在他们完成自己的目标时是否会协助或者阻碍他们的工作。

表1：举例说明当我们测试应用程序的时候我们以客户视角所提倡的一些做法。