迭代测试的21个谬论和事实

　本文来自于 Rational Edge：软件测试专家Laura Rose将会质疑和揭穿一些广泛流传的关于迭代开发和迭代测试通常的一些荒谬的言论。她将解释迭代开发原则是如何解决这些通常的误解的，并会把你带到测试方法的真正道路上。
　　谬论的产生是由于缺乏直接的经验。在缺乏信息的情况下，我们根据自己的想法形成了一些信念，并且会抱着怀疑的态度去看待我们所不知道的事情。在软件开发领域，荒谬的想法将会给接近客观真实的问题带来困难,因此把预算和时间推到了风险上。
　　在我作为质量保证经理的时候，我从大量的软件开发实践中获得了经验，这种经验包括迭代开发和称作“瀑布式”的方法。前者模型通常会被认为比后者的方法更加现代。但是这往往是一个荒谬的想法：两种方法都是产生于60年代。另外一个荒谬的想法是认为瀑布方法盛行于70年代。被誉为瀑布方法之父的Winston Royce认为这实际上是一种误解。他建议单向的瀑布方法只是为了维护项目而存在的。Royce建议在第一次开发软件应用程序的时候一个迭代要“执行两次”。
　　从这种误解开始，软件开发领域产生了很多荒谬的言论。这篇文章将会质疑和揭穿一些广泛流传的关于迭代开发和迭代测试通常的一些荒谬的言论。包括迭代开发原则是如何解决这些通常的误解的，并会把你带到测试方法的真正道路上，这种方法将会减轻和避免很多软件开发过程中的缺陷，其中有很多是被我们坚信的“谬论”。

　　谬论：在多数的软件开发项目中，我们带着抛弃这个代码的想法，很快的编写一个原型应用程序，用来降低风险和证明概念的正确性。
　　事实：这个方法没有任何问题。但是，由于时间的压力或者是结果的奖励，我们并没有抛弃这个代码。事实就是：我们的原型实际上就是早期代码。那个代码就成为了我们新的应用程序的基础和框架。然而，由于它是在假设会被抛弃的情况下建立的，它会迂回于需求评审，设计评审，代码评审和单元测试之间。我们下一代的应用程序是建立在不确定的基础之上的。
　　在迭代开发周期中，持续的验证是一个好的方法，在每一个迭代开发早期的原型是被鼓励的。但是任何的代码在提交到产品前，都需要遵照最佳实践，来保证它的稳定性和可维护性。一种鼓励在项目最开始做正确软件开发实践的方法是使用初始代码来计划，检验和呈现你打算在软件开发阶段全程使用的过程。作为迭代测试方法的一部分，你可以使用早期代码周期来测试你产品的概念，同时可以清除开发过程中的小故障。

　　谬论：在开发周期中过早的开始测试活动会增加产品交付的时间，降低产品的特性。
　　事实：测试在开发周期中不是耗时的活动。诊断并修正错误才是耗时的工作，是开发过程中的瓶颈。
　　测试不是导致我们产品搁浅的障碍——相反它是避免我们撞上岩石的灯塔。无论我们是否寻找错误，它都存在于产品中。迭代测试会帮助你接近它们产生的地点。迭代测试最小化了纠正错误的花费。

　　谬论：如果你没有完成的产品那么你就不能做测试。
　　事实：迭代测试并不被限制必须测试代码。
　　你的小组生产出来的每一个产品都可以根据可交付性的成功标准进行验证。同样的，你用来生产可交付使用产品的每一个过程或者程序都可以用你的成功的质量标准来确认。这包括产品概念，体系架构，开发框架，设计，方法和你遵循的开发程序。
　　你可以从这个局部列表中看到，多数的条目没有包括代码。因此，当你在等待有可交付使用代码时，你已经错过了维护质量和降低风险的机会。我不同意这个广泛接受的观念：“你不能对产品进行质量测试”。你可以这么做，只要你开始的足够早。
　　谬论：如果在每一个开发部分都有一名开发人员（或者一个单独的资源），那么你的工作将会更加有效率。在这个简单的论点中，如果你拥有30名开发人员，那么2人一队进行开发，你可以同时开发15个部分。如果你只给一个部分分配一名开发人员，那么你可以同时开发30个部分。这样会使你的产品完成度更高。
　　事实：一个部分只用一名开发人员完成有很大的风险：没有第二个人可以维护和理解这个部分的内容。这个策略产生了瓶颈和延迟。缺点，增加的需求或者修改会全部压在这个开发人员身上。为了按时完成工作，你的开发人员不得不为延长的产品周期而付出在周末加班的代价，因为他是这个部分唯一可以继续新特性开发和修正错误的人员。现在你的整个项目时间表都由这个英雄般的“单个开发人员” 1 负责。一旦这个人离开了小组，去度假或者出现一些不可控的情况，那么你的时间表将延期。由于你选择了这种执行和管理的开发策略，你现在不能对你的小组作出调整。
　　成对的开发，测试，代码评审和设计评审听起来更加有实际效果，它不但能增加产品的质量，还可以训练其他部分的人员，它能够增加你资源共享和维护项目代码的能力。一队中的两个人员不必要都是这个领域的专家。他们只要拥有可以消除先前讨论过的瓶颈问题的能力就可以了。
　　此外，把开发小组分成合理的更小的独立小组，能够使得拥有不同技术能力的开发人员在不同的方面更加有效的工作。一个小组分配多个人员，就可以避免把不同的任务分配给一个特定的开发人员。当你拥有多个资源可以分配的时侯，把一个任务分配给单个的开发人员会产生错误的依靠性。类似于银行的多个出纳员服务一条等待的客户队伍，当开发人员完成一个任务准备进入下一个任务的时候他们的效率会有所改进。

　　谬论：编写代码是开发人员的主要任务。
　　事实：在开发小组中每个人员的主要任务是生产符合客户需要的产品。这就意味着当你做需求评审活动时，开发人员的主要工作就是“需求的评审”。当你做设计活动时，开发人员的主要任务就是建立和评审设计文档。当你做代码活动时，开发人员的主要任务就是产生没有漏洞并且满足客户需求的代码。当你做文档评审活动时，开发人员的主要任务就是确保用户的辅助原料和错误信息能够使得客户的知识曲线变得平缓。当你做安装和设置工作的时候，开发人员的主要工作就是确保客户可以很轻松的设定和配置你的产品，这样他们就可以尽可能高效的完成他们“真正的”工作。越是需要更大的努力来使用软件完成任务，客户的投资回报率就会越低，应用程序失败的机率就会越高。

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

　　谬论：当代码设计的时间超过了时间表的计划，降低测试的时间可以帮助我们重新回到时间表的计划上。
　　事实：一般情况代码设计的延误是由于未预料到的困难或者没有按照最开始的设计工作。当我们发现我们低估了项目的复杂性的时候，缩短测试时间是一个糟糕的决定。相反，我们应该保证测试的执行，因为测试的结果是建立在我们低估代码设计的情况上的，测试的效果或许也会被低估。因此我们需要定制更多的测试时间来更正开始的判断，而不是减少测试时间。
　　迭代测试增加了测试时间但是并没有延误整个的时间进度，因为在每一个迭代过程中测试过程都是提前开始的。同样，产品的质量决定了需要测试的数量——而不是由时间决定的。例如，如果产品是可靠的，在很多领域都没有发现缺陷，并且测试进行的十分顺利，那么你可以在保证测试数量和测试覆盖率的前提下降低测试的时间。如果产品不够稳定，发现了很多缺陷，那么你需要增加测试的周期直到达到质量标准。请记住，测试并不是项目最耗时的工作。

　　谬论：找到并修正所有的缺陷将会建立一个高质量的产品。
　　事实：近来的研究显示，只有10%软件开发活动，例如建立客户需求特性，能够实际增加客户的价值。开发过程中加入一定比例的特性能够增加产品在市场中的竞争力，但是它们往往不是客户要求或者期望的。查找和修正这些缺陷不会增加客户的价值，因为客户可能永远也不会遇到这类的错误。
　　从另一个角度讲，迭代测试实际上会减少缺陷的数量和客户等待的时间，当然这是基于客户价值考虑的。在迭代过程中引入客户意见，迭代测试压缩对客户的交付周期，从而最大化应用程序对于这个客户的价值。

原文转自：http://www.ltesting.net