前段时间发布了《QA部门将会消亡》一文。

　　本文是一位测试专家对该文做出的回应。

　　就如同已经灭亡的皇室（国王已经消逝了，但是皇后却将永存），我们的软件开发正传递着类似的呼声：“测试已死，我们再也不需要测试人员了！”但随之你会发现，哎呀，客户不满意，最后又回到“测试万岁”，但这次是更好，更完整，更有效的测试。就如同历史上众多的复辟王朝（我最喜欢皇后伊丽莎白1世）一样，测试将强有力地帮助重新定义事物完成的方式以及它们的工作原理。

　　我打赌你现在正在想这不过是自我吹嘘而已，但是，事情是这样发生的：

　　让我们讨论一下测试的概念：什么是测试？测试就是考虑什么是“对的”的一个流程，定义方法以判断所测试的事物是否是“对的”，确定度量以明确“对的”是什么样子，理解“对的”的等级对团队其他人的任务和活动意味着什么，还有协助团队根据有用的信息做出好决策从而满足“对的”所必须的等级。

　　测试远不止随机敲击键盘以期找出问题这么简单；测试需要真正地理解所要求的解决方案，参与交付产品所采用的方法计划，了解交付方法所含的风险，同时还要尽早发现这些风险以便采取合适的补救措施。测试还需要驱动项目往成功的方向发展，并且帮助每个人理解成功所要求的合适水平。

　　为什么我们还需要关注测试呢，敏捷团队中的每个人不都在做测试吗？事实上并非如此。

　　所有的争议都是从质量的概念开始的。可能你会对自己说：“这简单。”如果你确实是这么想的，那就把它推到下一步…定义它。让你的开发团队、客户、产品所有者、项目经理以及组织中的首席信息官和首席执行官定义质量，要好好地定义，定义到足够好的程度。他们会同意吗？如果不同意，那这就是你的第一个问题。测试的任务就是帮助团队定义和理解质量所带来的影响。

　　“质量的影响？？这是什么？”这是你的下一个问题。事实上：质量是需要成本的！更糟糕的是：真正的高质量需要更高的成本！想真正建立质量，我们首先必须定义它，然后需要找到它。如果没有将质量建立到流程和技术中，没有将完整的各个级别的测试构建到我们的工作中，就不可能实现质量解决方案。

　　“啊，总算逮住你了”开发人员说道，“我们在敏捷中通过定义“完成”来明确质量”。“垃圾！”是我的答复。在我从事IT的所有时间里我听过最让人兴奋的概念就是定义“完成”—所有的组件，集中所有的知识，传递所有的信息……将解决方案的复杂性预先定义，所有的团队（开发和客户团队）都知晓所需要完成的任务以达到“完成”。定义“完成”让我想起了测试相关的一切。但是坏消息是我们并没有这么做！是的，我们没有这么做！就像我们不定义质量一样……我们只是假装我们定义了而已。哇~， 是否刺到你的痛处了？

　　为什么我这么说呢？首先，定义“完成”就如同定义质量一样，非常难。因为质量就像“美丽”一样，它是一个仁者见仁，智者见智的问题。测试的内容包括接受培训从而关注质量的定义，紧接着是对质量的探索（或者是质量缺陷），还有就是沟通在项目过程中依据进程、风险和剩余工作明确质量等级意味着什么。对于“完成”的定义也是如此，对于每个“执行者”（非旁观者）而言“完成”是不一样的，这允许我们理解“完成”的多个层次……我的完成，我们的完成，故事的完成，迭代的完成，特性的完成，发布的完成，产品的完成，项目的完成。

　　“这个没有关系，我们可以在其完成时再定义。”这是你对这个问题的机智回答。现在真正的挑战来了！定义“完成”与定义“很好地完成”是完全不一样的。“很好地完成”中的“很好”不仅仅是要完成目前产品中所要求的工作，还要明确我们如何知晓它达到了被要求的标准。每个层次的“完成”都有不同的完成标准，以及一个非常不同的“很好”的质量标准。团队中就有一群人不仅非常适合于协助定义“很好地完成”，同时还可以协助定义用于寻找“干得好”等级的流程和技术。

　　步骤一，定义“完成”…嗯，这看起来很简单嘛——保证执行者按照“完成”的等级完成所有需要交付的组件。好吧，目前为止听起来还不错。但是紧接着难点就来了…如果客户不满意，那么任何事情都不算“完成”。这就是敏捷宣言的基本属性之一。我引用了“可工作的软件胜过面面俱到的文档”这句话。因为一些不为人知的原因，人们往往会混淆“可工作”的定义与“完成”的定义，同时还会混淆“面面俱到的文档”这一概念与“良好测试”的定义。然后这就违背了原则“我们的最高目标是通过尽早持续地交付有价值的软件使客户满意”。那么是什么使软件具有价值呢？是不是交付产品？当然不是！而是该软件能很好地完成它所要完成的工作！！那么这算是我的“完成”，我们的“完成”，还是什么的“完成”呢……？

　　我们该如何去做呢？首先，我们需要认识到测试不仅仅是考虑开发和用户所关注的功能。功能要实现什么是非常简单的部分（简直就是轻而易举——我发誓）。功能很容易定义、构建和评估。功能倾向于二进制，类似“完成”与否的！“完成”有两个等级……“完成”和“未完成”……没有什么“几乎完成”这类说法。功能类似于煮食物……只有能与不能工作之说……二进制！但接着我们就进入了“完成”和随后的“很好地完成”领域，甚至更进一步的“为谁很好地完成？”。

　　测试关注于理解什么能使一个解决方案或方法对于使用它的人有价值。价值是上下文独立的，并且必须在项目和客户的上下文内定义。使用类似ISO9126之类的标准，根据它的6个质量特征（功能性，可靠性，实用性，有效性，可维护性和便携性）及其子特性，可以激发测试人员针对什么是好的、恰当的、有价值的这些问题进行讨论。但是更好的是我们需要真正的测试来找出这些价值。这类测试同样也需要时间和计划来很好地执行，如果想做得更好地的话，就需要更长的时间。