迭代测试的谬论与事实

在我作为质量保证经理的时候，我从大量的软件开发实践中获得了经验，这种经验包括迭代开发和称作“瀑布式”的方法。前者模型通常会被认为比后者的方法更加现代。但是这往往是一个荒谬的想法：两种方法都是产生于60年代。另外一个荒谬的想法是认为瀑布方法盛行于70年代。被誉为瀑布方法之父的Winston Royce认为这实际上是一种误解。他建议单向的瀑布方法只是为了维护项目而存在的。Royce建议在第一次开发软件应用程序的时候一个迭代要“执行两次”。

从这种误解开始，软件开发领域产生了很多荒谬的言论。这篇文章将会质疑和揭穿一些广泛流传的关于迭代开发和迭代测试通常的一些荒谬的言论。包括迭代开发原则是如何解决这些通常的误解的，并会把你带到测试方法的真正道路上，这种方法将会减轻和避免很多软件开发过程中的缺陷，其中有很多是被我们坚信的“谬论”。

谬论：在多数的软件开发项目中，我们带着抛弃这个代码的想法，很快的编写一个原型应用程序，用来降低风险和证明概念的正确性。

事实：这个方法没有任何问题。但是，由于时间的压力或者是结果的奖励，我们并没有抛弃这个代码。事实就是：我们的原型实际上就是早期代码。那个代码就成为了我们新的应用程序的基础和框架。然而，由于它是在假设会被抛弃的情况下建立的，它会迂回于需求评审，设计评审，代码评审和单元测试之间。我们下一代的应用程序是建立在不确定的基础之上的。

在迭代开发周期中，持续的验证是一个好的方法，在每一个迭代开发早期的原型是被鼓励的。但是任何的代码在提交到产品前，都需要遵照最佳实践，来保证它的稳定性和可维护性。一种鼓励在项目最开始做正确软件开发实践的方法是使用初始代码来计划，检验和呈现你打算在软件开发阶段全程使用的过程。作为迭代测试方法的一部分，你可以使用早期代码周期来测试你产品的概念，同时可以清除开发过程中的小故障。

谬论：在开发周期中过早的开始测试活动会增加产品交付的时间，降低产品的特性。

事实：测试在开发周期中不是耗时的活动。诊断并修正错误才是耗时的工作，是开发过程中的瓶颈。

测试不是导致我们产品搁浅的障碍——相反它是避免我们撞上岩石的灯塔。无论我们是否寻找错误，它都存在于产品中。迭代测试会帮助你接近它们产生的地点。迭代测试最小化了纠正错误的花费。

谬论：如果你没有完成的产品那么你就不能做测试。

事实：迭代测试并不被限制必须测试代码。

你的小组生产出来的每一个产品都可以根据可交付性的成功标准进行验证。同样的，你用来生产可交付使用产品的每一个过程或者程序都可以用你的成功的质量标准来确认。这包括产品概念，体系架构，开发框架，设计，方法和你遵循的开发程序。

你可以从这个局部列表中看到，多数的条目没有包括代码。因此，当你在等待有可交付使用代码时，你已经错过了维护质量和降低风险的机会。我不同意这个广泛接受的观念：“你不能对产品进行质量测试”。你可以这么做，只要你开始的足够早。

谬论：如果在每一个开发部分都有一名开发人员（或者一个单独的资源），那么你的工作将会更加有效率。在这个简单的论点中，如果你拥有30名开发人员，那么2人一队进行开发，你可以同时开发15个部分。如果你只给一个部分分配一名开发人员，那么你可以同时开发30个部分。这样会使你的产品完成度更高。

事实：一个部分只用一名开发人员完成有很大的风险：没有第二个人可以维护和理解这个部分的内容。这个策略产生了瓶颈和延迟。缺点，增加的需求或者修改会全部压在这个开发人员身上。为了按时完成工作，你的开发人员不得不为延长的产品周期而付出在周末加班的代价，因为他是这个部分唯一可以继续新特性开发和修正错误的人员。现在你的整个项目时间表都由这个英雄般的“单个开发人员” ¹ 负责。一旦这个人离开了小组，去度假或者出现一些不可控的情况，那么你的时间表将延期。由于你选择了这种执行和管理的开发策略，你现在不能对你的小组作出调整。

成对的开发，测试，代码评审和设计评审听起来更加有实际效果，它不但能增加产品的质量，还可以训练其他部分的人员，它能够增加你资源共享和维护项目代码的能力。一队中的两个人员不必要都是这个领域的专家。他们只要拥有可以消除先前讨论过的瓶颈问题的能力就可以了。

此外，把开发小组分成合理的更小的独立小组，能够使得拥有不同技术能力的开发人员在不同的方面更加有效的工作。一个小组分配多个人员，就可以避免把不同的任务分配给一个特定的开发人员。当你拥有多个资源可以分配的时侯，把一个任务分配给单个的开发人员会产生错误的依靠性。类似于银行的多个出纳员服务一条等待的客户队伍，当开发人员完成一个任务准备进入下一个任务的时候他们的效率会有所改进。

谬论：编写代码是开发人员的主要任务。

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