迭代测试的谬论与事实

谬论：我们没有足够的资源和时间来全面测试产品。

事实：你不需要全面测试产品——你需要充分测试产品来减少一个客户将被消极地影响的风险。

变化市场的事实通常要求在给定的时间框架中详尽地测试一个产品，但事实上是不可能的。这就是我们需要测试的一个实用方法的原因。关注于你的客户的商业过程来确定你的测试优先级。联合系统的内部客户来测试你的产品。当提供真实世界可用性的反馈时，这些步骤增加了你的测试资源。同时你也可以在一个外部客户实验室中来做你的系统测试，来增长你的真实世界环境的经验而不用增加你的维护或系统管理活动。

谬论：测试应当发生在一个被控制的环境中。

事实：测试环境越象最终产品环境，测试越可靠。如果客户环境被严格控制，那么你可以在一个被控制的环境中做你所有的测试。但是如果最终产品环境没有被控制，那么你在一个被控制的环境中做你测试的100%的工作将会使你错过一些重要的情况。

尽管难以预测的事件和不同的环境难以效仿，但它们是十分常见的，因此也是值得期待的。在我们当前的全球市场能够中，你的应用软件将被用于灵活的，分布的，和多变的情况是十分可能的。在迭代测试中，我们因此根据处于不同环境中的客户来同时确定商业使用模型检查和系统测试活动的时间进度。早期的商业使用检查确定目标客户市场的差异性，优先于编码。在客户现场进行系统测试是在真实世界中运用了我们的产品。尽管产品的这些“预发布”版本仍然在我们开发人员的手中，并运行于我们的工作站上，但它们已经在客户真实世界的办公室（或实验室）的环境和应用软件中被测试。尽管这个策略不能覆盖每一个可能性，但它承认不可预知性的存在。

谬论：所有的客户有着同等的重要性。

事实：一些客户要比其他客户更加重要，这是基于一个特殊发布的目标。例如，如果一月发布的发布定义特性是将传统MyWidget数据转变为MyPalmPilot的特性，那么我们的用户使用MyWidget和MyPalmPilot的反应对于这个特殊的发布来说，要比其他客户的输入更加重要。

所有我们的客户当然都是重要的。但是迭代测试的目标是关注于这个特殊迭代法的最重要特性。如果我们正在将特性XYZ输送到这个迭代法中，我们需要来自于熟悉优先的XYZ功能的使用者的专家对XYZ的评价。就象我们欢迎其它反馈一样，诸如新使用者的印象，XYZ特性的优先考虑。在开发的这个阶段，刚刚接触市场的使用者不能帮助我们设计“正确的XYZ特性”。

谬论：如果我们正在寻找很多程序缺陷，我们正在做重要的测试。

事实：找到很多程序缺陷的唯一好处就是告诉我们产品存在很多程序缺陷。它没有告诉我们测试覆盖的质量，程序缺陷的严重性，或是客户将在实际中碰到它们的频率。同样它也没有告诉我们遗留下多少程序缺陷。

停止找到程序缺陷的唯一确定方法就是停止测试。它看起来是荒谬的，但这个想法是有价值的。这个难题的症结在于指出产品的什么特性确实需要研究。我已经提到产品中的许多工作流实际没有被使用——并且如果它们没有被使用，它们就不需要被研究。直接在你的测试计划中合并客户使用知识以及缺点筛余机制提高了你预测客户影响和与缺点相关的风险概率。在你的测试计划解决中合并基于风险和客户分析将产生一个更加实际和实用的测试计划。一旦你对你的测试计划有信心，你可以在你已经执行计划之后停止测试。

你如何建立那种信心？开始你的测试计划时要确定你需要测试的所有区域。让客户检查和评价商业过程并使用实例以便你懂得每一个被提议的测试实例的频率和重要性。要特别注意检查测试漏洞。对每一个迭代要持续更新和检查你的测试计划和测试实例。你的目标是找到什么没有被覆盖到。做到这个的一种方法是通过软件区域和测试种类来映射程序缺陷计数。如果一个软件区域没有被记录缺点，它可能意味着这个区域是十分有效的或者它还没有被测试。看缺陷文件的时间戳。如果最后的缺陷是去年公布的，可能它暂时不用被测试。找到错过的程序错误的模式是检查测试覆盖的一个重要技术。