谬论：客户总是正确的。  

    事实：可能他不是一个正确的客户。你不可能使用一个发布来使每一个人都满意。因此，要在你的发布定义特性设置中有选择性。瞄准一个特殊的，高度概括的测试场作为用户的一种类型目标。然后对于下一个发布或迭代，选择一个不同的人群。你将更有效地测试；当你的产品成熟的时候，你将通过在不同阶段中增加满意的客户来增加你的客户基础。

    谬论：自动化！自动化！自动化！

    事实：在脑海中客观的看待自动化，并考虑 ROI。测试环境越象最终产品环境，测试的可靠性越高。如果客户的产品是100%自动化的，那么自动化！自动化！自动化！如果你的产品不打算在客户环境中实现自动化，那么你需要将自动化的，特殊化的，探查的以及客户场景的测试进行合并。

    它同时对于扩展你的自动化定义有所帮助。自动化测试实例可以重复测试你已经手工测试过的区域。但是那不能增加你的测试覆盖或你对使用者对于应用软件是如何反应的理解。相反，创建自动化实际上允许你投入更多的精力在创造性的手工测试上。使事情自动化是你经常需要做的并且那将使你花费很长的时间来完成，象：

    *分解和建立原始环境来测试每一个构建。
    *对每一个构建，集成点，或迭代的全面验收测试。
    *跨越各种平台，操作系统和语言测试相同的套件，。
    *低级别组件的单元和命令行测试。
　
    为了得到更多关于增加你的对自动化投资回报的信息，访问http://www-128.ibm.com/developerworks/rational/library/may05/rose/。

    谬论：迭代开发行不通。

    事实：它是人类对于未知和未尝试的领域怀疑的天然属性。在迭代开发经验中，每一个成功阶段的好处逐渐增加。因此，迭代方法的所有好处是只有在开发周期的末尾才被重视。对于第一个吃螃蟹的人来说，那个推迟的满意可以真正地成为信念的行为。我们没有使用方法的经验，并且所以我们不太信任即将使用的方法。当我们认识到时间正在流逝，我们放弃了信念并抛弃了迭代过程。在恐慌状态中，我们又回到了我们的老习惯。迭代开发多半没有实际失败。我们只是没有给它一个成功的机会。

    迭代测试在迭代开发的累积好处的每一个迭代中提供了可见的记号。当团队共享增加的成功标准（例如，每一个迭代的进入和退出标准）时，站在正确的方向上是更加容易的。

    因为我们根据出口标准持续监控结果，我们可以更容易地在迭代中调整我们的测试来达到我们的最终目标。例如，在中间迭代中，我们可以观察我们关键的和高缺陷计数在增长，并且我们可以比修正它们更快地找到它们。因为我们早已经认识到这个趋势，我们可以重新分配资源来加深对于关键路径活动的关注。我们可以再分配研究“乐意拥有” 特性的开发人员来修正“发布定义” 特性中的缺陷，或者删除与高缺陷计数有关的乐意拥有特性。

    结论

    我只接触到了我们假设每天都会遇到的软件开发的谬论中的少数一部分。如果我们假设做得越多，我们就会越少发现不可预知的事情——所有关于软件测试的。

    不幸的是，我们提到的谬论是非常诱人的。它们被伪装成答案，并且它们方便地结束了对话。当我们人员不足并承受压力时，接受假设作为事实是非常诱人的。

    因为我们经常难以分辨谬论和事实，我们需要检查我们的答案。这个简单而有效的颂歌，总结了我已经在这篇文章中论述的所有东西，将有助于你保持在正确的轨道上：迭代测试从来都没有满意的正确答案。

    注解

1 在能力成熟度模型 （CMM，或CMMI）中，通过依靠少数几个个人英雄主义的劳动典型的是成熟度 1 级的水平，也就是众所周知的混乱级别。