谬论：找到并修正所有的缺陷将会建立一个高质量的产品。
事实：近来的研究显示，只有10%软件开发活动，例如建立客户需求特性，能够实际增加客户的价值。开发过程中加入一定比例的特性能够增加产品在市场中的竞争力，但是它们往往不是客户要求或者期望的。查找和修正这些缺陷不会增加客户的价值，因为客户可能永远也不会遇到这类的错误。
从另一个角度讲，迭代测试实际上会减少缺陷的数量和客户等待的时间，当然这是基于客户价值考虑的。在迭代过程中引入客户意见，迭代测试压缩对客户的交付周期，从而最大化应用程序对于这个客户的价值。
谬论：不断的回归测试每一件我们更改的代码是十分冗余和费时的工作，只有在理想化的世界中才会这么做。
事实：回归测试并不意味着“每次测试每件事”。
迭代回归测试的意思是测试每个阶段中敏感的部分。它也意味着基于改动效果，产品历史和早期测试结果而更改我们的测试覆盖率。
如果你的回归测试是自动执行的，那么你可以在同时运行所有测试。如果不是，那么请选择你想要完成测试的部分进行测试。例如，你可以在“验收”产品之前之前运行一个“完整的回归套件”或者“一系列验收测试”f。由于每一个回归过程都不是必须相同的，测试不需要每一次都相同。把精力集中在特性和测试上面对于即将到来的交付阶段是十分有意义的。例如，如果你使用第三方的组件，比如一个承包商或者开源的产品，完整的回归套件将会把焦点集中在外部和内部组件的集合点上。如果在你初始化第三方模块完整回归测试时，发现了缺陷或者回归，那么你可以选择添加基于早期结果的额外测试来改变你的回归套件。
换句话说，如果你在你的控制之下在整个产品开发中进行一系列的缺陷修复工作，那么完整的回归套件应该被完全聚焦并构建在你的端到端，高概括的客户用例上。如果更改被限制在一个领域，并且产品拥有一个稳定的质量追踪记录，那么你可以把精力全部集中在这个回归套件中。同样，在最后阶段，你或许需要一个非常小的能够覆盖介质安装的完整回归套件，但并不是深层次的或者端到端的测试。完整或者验收回归套件的重点依赖于在前一个周期测试了什么，产品的一般稳定性和下一个迭代的重点。
谬论：这不是一个缺陷——特性随着设计而出现。
事实：过多的解释为什么产品会做它现在正在做的事情是一个普遍的陷阱。有时候我们知道的太多了。当缺陷被修复和评审的时候，我们经常为缺陷自圆其说。有时候我们把缺陷标志成为“伴随设计更正”或者“不计划修复”，因为应用程序实际上是伴随着设计工作的，更改设计将是过于昂贵和具有风险的。同样的，我们解释了很多关于“它是一个外部组件”或者“它是一个钟表或者汽笛”的可用性。我们的窗口小部件或者 UI 控件将会受到限制。或者我们告诉我们自己“一旦用户知道要这么做，他们将会很好”。
总而言之：我们了解了代码的输入和输出，以及他们为什么这么工作。在这个部件层次上，我们做了非常合理和明智的决定。但是我们缺少对整个客户经验的整体观。我们没有给我们编码平衡和工作区带来最终效果增值。我们的主要聚焦点是使重要的代码按时完成。通过聚焦于个别的特性或者组件，我们不经意的做了一些代码的决定，这对产品的全面流程和可用性产生了消极的影响。毕竟，最大限度影响客户效率的是可用性。而驱使用户放弃一定数量功能的也是可用性。
超过上面的细节层次提升我们对于项目的见解，会允许我们以客户期待的视角看待我们的产品——通过全局的层面，而不是单个的组件。这种提高后的视角帮助我们忽略了对于产品为什么这么工作的所有原因的探究。客户不会关心给定的设计是否会加快代码的设计。对于客户来说用户界面是否与你特定开发任务外的组件X的API冲突与他们无关。他们只关心这个产品在他们完成自己的目标时是否会协助或者阻碍他们的工作。
谬论：一个测试人员的唯一任务就是找到程序缺陷。
事实：关于测试人员的作用的这个观点是非常有局限性的，并且对于客户没有增加价值。测试人员都是被测试系统，应用软件或产品的专家。不象负责一个特殊功能或组件的开发人员，测试人员懂得系统作为一个整体是如何工作的来达到客户的目标。测试人员懂得由产品增加的价值，关于产品效率的环境的影响，以及从产品得到最多输出的最好方法。
通过这个产品知识扩展了我们测试人员的价值和作用。扩展测试人员的作用（诸如技巧，技术，指导方针，以及为使用而进行的最佳练习）最终减少了客户所有权的成本和增加了测试人员的商业价值。 谬论：我们没有足够的资源和时间来全面测试产品。
事实：你不需要全面测试产品——你需要充分测试产品来减少一个客户将被消极地影响的风险。
变化市场的事实通常要求在给定的时间框架中详尽地测试一个产品，但事实上是不可能的。这就是我们需要测试的一个实用方法的原因。关注于你的客户的商业过程来确定你的测试优先级。联合系统的内部客户来测试你的产品。当提供真实世界可用性的反馈时，这些步骤增加了你的测试资源。同时你也可以在一个外部客户实验室中来做你的系统测试，来增长你的真实世界环境的经验而不用增加你的维护或系统管理活动。
谬论：测试应当发生在一个被控制的环境中。
事实：测试环境越象最终产品环境，测试越可靠。如果客户环境被严格控制，那么你可以在一个被控制的环境中做你所有的测试。但是如果最终产品环境没有被控制，那么你在一个被控制的环境中做你测试的100%的工作将会使你错过一些重要的情况。
尽管难以预测的事件和不同的环境难以效仿，但它们是十分常见的，因此也是值得期待的。在我们当前的全球市场能够中，你的应用软件将被用于灵活的，分布的，和多变的情况是十分可能的。在迭代测试中，我们因此根据处于不同环境中的客户来同时确定商业使用模型检查和系统测试活动的时间进度。早期的商业使用检查确定目标客户市场的差异性，优先于编码。在客户现场进行系统测试是在真实世界中运用了我们的产品。尽管产品的这些“预发布”版本仍然在我们开发人员的手中，并运行于我们的工作站上，但它们已经在客户真实世界的办公室（或实验室）的环境和应用软件中被测试。尽管这个策略不能覆盖每一个可能性，但它承认不可预知性的存在。
谬论：所有的客户有着同等的重要性。
事实：一些客户要比其他客户更加重要，这是基于一个特殊发布的目标。例如，如果一月发布的发布定义特性是将传统MyWidget数据转变为MyPalmPilot的特性，那么我们的用户使用MyWidget和MyPalmPilot的反应对于这个特殊的发布来说，要比其他客户的输入更加重要。
所有我们的客户当然都是重要的。但是迭代测试的目标是关注于这个特殊迭代法的最重要特性。如果我们正在将特性XYZ输送到这个迭代法中，我们需要来自于熟悉优先的XYZ功能的使用者的专家对XYZ的评价。就象我们欢迎其它反馈一样，诸如新使用者的印象，XYZ特性的优先考虑。在开发的这个阶段，刚刚接触市场的使用者不能帮助我们设计“正确的XYZ特性”。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
