一个被广泛采用的BDD可以带来不同。这只是分享同一个例子的问题，在软件开发的三个主要角色上有相同的共识。这会带来不同，因为你减少了误解、重复和无用的功能。它之所以有效，是因为它专注于做正确的功能，而不是做正确的功能。
经典的BDD采用策略
经典的策略是教三个主要角色通过Gherkin 进行协作。业务人员学习编写场景，开发人员将其转换为代码，QA验证它们。但在这种采用中有一个共同的问题：Gherkin是一种编程语言，企业不知道如何编写代码。
开始写Gherkin 有一个次要的影响：开发者通常认为商业是一个无可争议的权威。因此，开发人员没有勇气帮助企业修复场景。QA在这方面取得了更大的成功，因为他们把Gherkin 视为质量测试，他们对质量有最终决定权。
这就是问题所在。开发人员是唯一能够正确处理编程语言的人，他们太忙，太害怕，无法提前采用。因此，采用失败，并以两种可能性之一告终：BDD停止，或BDD继续处于次优状态，永远无法充分发挥其潜力。
由内而外的BDD采用策略。
这种策略是如此明显，以至于我不知道我们怎么都没有注意到它。
BDD是开发人员的需求，而不是业务，也不是QA。开发人员创建它是为了满足它的需求，然后它传播开来。BDD在开发者手中太强大了，以至于它一直在增长和传播，直到今天。那么，为什么不复制这种策略呢？
由内而外的BDD采用策略是模仿BDD本身的创建，但速度更快。它是由内而外的，因为它从开发人员开始，并通过业务和QA展开。在这个策略中，BDD不是传授的东西，而是希望的东西。
要了解这项工作的原因，我们需要了解开发人员在日常工作中面临的问题。开发人员收到用模糊语言编写的指令，他们必须进行解释和实现。一旦他们完成了，QA就会审查他们的工作。QA增加了自己的标准，QA可能会提出不同的需求和要求。开发人员正在进行猜测和重做。
BDD可以作为一种工具呈现给开发人员，以避免猜测和重复。在任何工作之前，如果有不清楚的地方，开发人员可以正确地编写Gherkin 场景。他们会把它作为一个商业例子，因为它读起来像英语，他们会有明确的回应。QA也是一样，如果他们认为在任何可能引起讨论的边缘情况下，他们可以在编写代码之前编写场景，然后询问QA。对于开发者来说，Gherkin 成了解决疑问和避免重复的工具。
后来，随着Gherkin 的来来往往，企业会了解Gherkin 以及它们如何影响产品行为。他们学到了一些只有通过实践才能学到的东西。QA也是如此。这两个角色都是在开发人员的日常实践中开始学习的，所以最终，所有人都会齐心协力。
有好多人好奇Gherkin 是什么？Gherkin是一种商业可读的、特定于领域的语言，专门为行为描述而创建。它使您能够从行为测试中删除逻辑细节。
