实例化需求术语解读

首先我想解释一下，为什么我选择实例化需求说明作为这些实践的总称，而没有使用敏捷验收测试、行为驱动开发或者验收测试驱动开发。

在2010年的伦敦领域驱动开发交流大会 上，Eric Evans跟别人争论，说敏捷作为一个术语已经失去了一切意义，因为现在什么都可以称为敏捷。很不幸的是，他是正确的。尽管有大量的著作讲如何正确地实施极限编程、Scrum以及其他不那么流行的敏捷过程，但我见过太多太多的团队，试图去实现冠以敏捷一词的过程，但那些过程又显而易见地违背了敏捷的精神。

为了避免这种关于敏捷是否可行（以及什么是敏捷）的无意义争论，在本书中，我尽量避免使用敏捷这一术语。只有当我提到的团队基于敏捷宣言概括的原则定义了良好的过程，并开始实施时，我才会使用它。由于不会经常提到敏捷这一术语，敏捷验收测试这个名称也就无从谈起了。

这里描述的实践没有形成一个成熟的软件开发方法论。它们可以补充其他方法论——无论是基于迭代还是基于工作流的——使需求说明和测试更加严谨，增强不同项目干系人和软件开发团队成员之间的沟通、减少不必要的返工，并让改变更加容易。因此我不想使用任何“驱动开发”之类的名字，尤其不会使用行为驱动开发（BDD）的字眼。不要认为这说明我反对BDD。恰恰相反，我喜欢BDD，而且我认为本书实际上主要在讲BDD的核心内容。但BDD同样有名字歧义的问题。

BDD到底代表了什么总是在变化。关于什么是BDD，什么不是BDD，Dan North是最具话语权的。在Agile Specifications, BDD, and Testing Exchange 2009 上，他说BDD是一种方法论。（事实上，他将其称为“第二代的、由外而内的、基于拉动的、多项目干系人、多尺度的、高度自动化的敏捷方法。”）为了避免在North所说的BDD和我理解中的BDD之间产生任何混淆和歧义，我不想使用这个名字。本书讲的是一组宝贵的实践，在很多方法论中你都可以使用，包括BDD（如果你能接受BDD是一种方法论的说法）。

我也想尽量避免使用测试这个字眼。很不幸地，很多经理和业务人员认为测试是一种技术辅助活动，不是他们想参与的事情。毕竟，他们有专门的测试人员去处理这件事情。实例化需求说明要求项目干系人以及交付团队的成员（包括测试人员、开发人员、业务分析人员）积极地参与进去。只要我们在标题中不放入测试这样的词汇，那么故事测试、敏捷验收测试以及其他类似的名字自然就不会出现。

这让实例化需求说明成为了最有意义的名字，它的负面影响最小。

过程模式

实例化需求说明由一些过程模式（Process Pattern）组成，后者是更广义的软件开发生命周期的组成要素。本书中我用的名字是在英国敏捷测试用户组会议、敏捷联盟功能测试工具邮件组以及工作坊中经过一系列讨论得到的。其中有些名字已经用了一段时间，而另一些大多数读者还比较陌生。

业内流行用一个实践或工具的名字来描述过程的一部分。功能注入（Feature Injection）就是一个很好的例子——用它来描述从商业目标中获取项目范围这一过程，就很受欢迎。但是功能注入只是其中一种技术，还有其他方法可以达到同样的目的。为了讨论不同的团队在不同的环境中做什么，我们需要更宏观的概念来囊括所有这些实践。一个好的名字能很好地说明预期的结果，并且清晰地指出这些实践的关键区别。

以功能注入与类似实践为例，其结果就是项目或里程碑的一个范畴。与其他定义范围的方法相比，关键区别在于，我们专注的是商业目标。因此我提出从目标中获取范围（deriving scope from goals）这一概念。

在实例化需求说明过程中，团队碰到的最大的一个问题是：谁应该在什么时候写些什么东西。所以我们需要一个好名字来明确地说明大家都应参与（需要在团队开始编码或测试前做），因为我们要使用验收测试作为开发的目标。测试先行（Test First）是个不错的技术名词，然而商业用户并不能理解，更何况它没有包含合作的意思。我建议我们关注通过协作制定需求说明（specifying collaboratively），而非测试优先或写验收测试。

听起来很普通，只是把每个数字上的可能性考虑进自动化功能测试里。如果自动化了，我们为什么不这么做？但是如此复杂的测试作为沟通工具是无法使用的，在实例化需求说明里，我们是要用测试来沟通。因此不是编写功能测试，而是关注举例说明（illustrating using examples），并且期望它能输出关键实例（key examples）这些实例表明我们只需要恰当地描述所需的环境就可以了 。

关键实例是原料，但是如果仅仅关注验收测试，为什么不干脆就用50列100行的复杂表格来作为实例，并且不带任何说明？反正是机器来测试。用了实例化需求说明，测试既是给机器看的，也是给人看的。我们需要说清楚的是，使用实例说明后，还有一个步骤，就是抽取属性和实例的最小集合来说明业务规则，并加上标题和描述等。我建议把这个步骤称为提炼需求说明（refining the specification） 。

提炼的结果既是需求说明，同时也是开发的目标、检查验收的客观方法以及之后的功能回归测试。我不想叫它验收测试的原因是，它很难说明为什么文档要用领域语言来写、可读性要高，还要容易理解。我认为我们应该将提炼的结果称为带实例的需求说明（specification with examples），从而揭示出一个事实，就是需求说明需要基于实例，但绝不是只包含原始数据。将这个工件称作需求说明可以明显地指出大家都需要关注它，而且它需要容易理解。除此之外，关于是否用这些检查来自动验收软件或自动拒绝不满足需要的代码，还有另外一种截然不同的观点 。

我不想再花时间和那些买了QTP的人争论，告诉他们QTP对验收测试完全没有用。只要我们谈论测试自动化，总有人推销测试人员已经用来做自动化的可怕玩意儿。敏捷验收测试和BDD工具与QTP之类的工具有很大的差别，它们处理完全不同的问题。不应将需求说明解释成一种自动化的技术。我们把在不歪曲任何信息的情况下将验证自动化称作自动化验证而不改变需求说明（automating validation without changing specifications），而非验证自动化。不改变原有需求说明的自动化验证可以帮助我们避免可怕的脚本和在测试需求说明中直接使用技术类库。可执行的需求说明应该与在白板上看到的一样，而不应该转译成Seleninum命令。

在将需求说明验证自动化后，我们可以用它来验证系统。事实上，我们得到了可执行的需求说明（executable specification）。

我们要频繁地检查所有的需求说明，确保系统还在按所期望的运行，同样重要的是确保需求说明还能描述系统的行为。如果我们将这称作回归测试，那么很难向测试人员解释为什么他们不应该在之前既小又好而且明确的需求说明中再加500万个测试用例。如果再提到持续集成，我们将很难解释为什么不总是端到端地运行这些测试，并检查整个系统。对于一些遗留系统，我们需要针对一个部署好的正在运行中的环境来运行验收测试。技术上的集成测试应在部署前运行。所以我们不谈回归测试或持续集成，我们谈频繁验证（validating frequently）。

实例化需求说明具有长期回报，前提是拥有一个对系统自身功能的引用，该引用具有与代码一样的价值，但是更易读懂。长期来说，这使得开发有效率得多，能促进与商业用户的合作，促成软件设计和商业模型的一致，并且使大家工作更简单。但是要做到这点，该引用必须有意义，必须有人维护，而且还必须内部保持一致，并与代码保持一致。我们不应该有大量的测试还在用数年前使用的术语。你很难让忙碌的团队回过头去更新测试，但是在重大改变之后回头去更新文档，这是大家所愿意看到的。所以我们不要关注那些含有数百个测试的文件夹，让我们把注意力放到演化活文档系统（evolving a living documentation system）上。这样就更容易解释，为什么很多事情必须不言而喻，为什么商业用户也需要使用这些，为什么需要良好地组织以方便查找。

所以情况就是这样：我选择了这些名字，不是因为它们以前很流行，而是因为它们有意义。这些过程模式的名字必须创建一种思考模型，该模型可以明确地指出那些重要的事，并且减少困惑。我希望你能明白这点，并接受这个新的术语。