Hindsight Software的创始人兼CEO Alan Parkinson说，他在作为软件开发员和工程师之后几年走进了质量测试领域。是什么吸引他到软件QA这一思想，且超越了开发？是因为软件QA确保了开发人员的工作。“没有高质量软件，购买者就会到其它的地方去了，” Parkinson说。“如果他们不买、卖方歇业，我们软件开发者都失业了。”最近在麻省理工，每月的波士顿Java讨论组（Boston Java Meetup Group）上，Parkinson在Java开发人员，谈到使用行为驱动开发(BDD)和开源自动化测试Cucumber。

　　BDD是一种开发方法，建立于测试驱动开发和验收测试驱动开发之上。后者开发方法强调的重点是开发测试，来在软件开发完成之前证明软件是正常运作的的，测试员说。通过声明验收测试应该是由完成应用的预期行为，BDD将这个概念进一步说明。Parkinson声明，此行为驱动方法改进了需求定义，从而降低了引进需求缺陷的机率。

　　Parkinson说，大多数缺陷分为两大类。一方面是实现缺陷：代码是的作用不计划那样的。另一方面是需求缺陷：开发人员给错误的函数编写了正确的代码。Parkinson说，50%到60%的缺陷是需求缺陷，他们修复的昂贵代价是100%到200%的。对于实现缺陷，开发人员通常可以隔离部分错误代码，然后修复它就可以了。另外，需求缺陷通常意味着重设计和重编码整个项目。

　　Parkinson推荐使用开源工具Cucumber，用它帮助自动化验收测试，以及BDD。有了Cucumber BDD工具，应用开发团队能够使用自然语言格式Gherkin，来代表行为驱动需求，产生与这些需求相对应的自动化测试，然后迅速产生一个最小的文档。

　　Gherkin是一门自然语言，所以业务代表和利益相关者能够阅读并理解他们。尽管如此，Parkinson说，用Cucumber撰写需求场景是最适合开发人员或QA专业人士的工作。“高管可以理解Cucumber需求场景，但这并不意味着他们会开始写他们。这不是一个能创造奇迹的工具,” Parkinson讽刺说。Gherkin使用了一个相当流行的测试场景格式，称为Given-When-Then。一个特别简单的例子是，“假设用户已经登录到我的‘Hello World’程序；当用户点击‘GO’；然后程序应该显示‘Hello World！’”

　　据Parkinson所说，这对于软件开发团队的所有人员都很重要——包括利益相关者和质量保证测试员，以及软件设计和编码人员，在同一页上的从头到尾的需要都很重要。这就是为什么使用像 Gherkin这样的自然语言来编写最终验收测试场景很重要的原因了。这帮助利益相关者、QA测试员和编程人员都对于那些需求的意义共享同一理解。　　

Mike Cohn的测试自动化金字塔

　　Cucumber读取Gherkin，输出样板代码，它模仿了Gherkin的规范规定，这很好，Parkinson说。他说，无论是谁负责自动化验收测试，都能快速地从Gherkin测试场景中直接产生测试代码，以相关必要代码的调整。他解释说，在大部分组织中，他已经看到了开发人员产生的自动化验收测试，但这在另一个组织中，测试人员可能已经编码出了这些测试，或者可能要求去学习足够的代码来产生他们。

　　一旦验收测试已经产生，Parkinson建议，开发团队应该紧紧地跟随这些单元测试，并常常运行他们。这将会确保验收测试场景的每一步都完成了。跟着Mike Cohn的测试自动化金字塔，Parkinson解释了Cucumber BDD专注于金字塔基础，这代表的所有测试的80%到90%。大多数组织仍然需要手动探索测试，在边缘的情况下，来看看并感受一下测试和其它必须的东西，Parkinson说。

　　Parkinson还说，Gherkin规范加倍了软件文档的基线，此文档描述了回归测试，解释了基本的应用行为。对于敏捷团队在缩小文档工作的坚持上，这可以作为一个最小形式的需求文档、设计文档,甚至技术文档。然而，这些规范将肯定有足够的技术以适应用户文档。

　　Parkinson承认用户文档在Cucumber项目中是“不抢眼的”。“与许多开源项目一样，Cucumber BDD项目文档是正在进行的工作。它目前正在编写，并对Cucumber社区可用，” Parkinson说。