有关 BDD 概念,请参考 BDD - 介绍 Behavior-Driven Development 行为驱动开发,本文主要结合 Agile,发挥 BDD 在整个团队的作用。
Agile 敏捷开发是一个增量的,迭代的,协作的软件开发过程。Team 团队计划一个 Sprint 周期的 User Stories 用户故事,这些 Story 都有验收标准,团队围绕 Story 的工作(开发,测试,自动化)都必须完成。
来自 the Agile Manifesto 敏捷开发宣言
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
个体和交互胜过过程和工具
可运行的软件胜过详尽的文档
客户参与协作胜过合同谈判
响应变化胜过遵循计划
BDD 通过协作和简化流程来提高质量。有助于规范验收测试。
Acceptance Criteria 验收标准是一系列用来接收和检验 Story 完成必须满足的条件。Acceptance Tests 验收测试是覆盖验收标准的场景测试。
例如: 一个行为驱动的用户故事 A Behavior-Driven User Story
User Story
As a Baidu user
I want to search for some terms
So that I can get info for my search
Acceptance Criteria
Given a user is on Baidu home page
When the user searches for “BDD”
Then the results page shows document links for “BDD”
我们可以得出:
Requirements 需求 = Acceptance Criteria 验收标准 = Tests 测试!
BDD 帮助团队方便将验收测试转换成自动化测试。Acceptance criteria 验收标准往往被忽略,它可能缺失或漏写,导致团队误解,从而引发浪费时间,Story 的不完整,无效的 features. Gherkin 语言规范化验收标准来提高沟通,规范化也使得测试方便被自动化。
Shift Left 左移是在软件开发生命周期尽早
开展测试和 QA 工作。尽早发现问题意味着后面花更低的成本.
BDD 就是左移,因为验收标准可以在一个 Spring 早期用 Gherkin 编写,开发在实现功能的同时,QA 可以准备测试。
因为 BDD Scenario 场景是用直白的语言写的,所以每个人都能理解。
对 PO (product owners) 来说,它们是需求
对开发来说,它们是验收标准
对自动化工程师来说,它们是脚本
对其它 stakeholders 利益相关人员,它们是描述,说明规格
Agile 的三个主要角色,PO(Product Owner), Developer 开发, 和 Tester 测试,他们是三个好朋友。
他们定期开会:
这三个好朋友的目的就是为了让所有人都达成一致 on the same page !
在一个传统 Sprint 周期,Story 的各阶段进程是顺序的。测试行为通常是在 Sprint 的后期进行,如果有问题,将造成 Story 不能完成的风险。
在一个行为驱动 Sprint 周期,三个好朋友在开始时就会面,QA 可以领先将验收标准翻译成 Gherkin Scenario,然后自动化跟开发并行执行。
理想情况下,当一个团队非常擅长 BDD,在提交 Story 到一个 Sprint 之前,将验收标准 Gherkin 化在梳理 Grooming Story 时期进行。PO 也可以帮助 QA 开始用粗略的 Gherkin 写验收标准。