Master
ThoughtWorks
菜单
关闭
  • 产品及服务
    • 概况
    • "客户体验、产品及设计业务线 "
    • 数据战略、工程及分析业务线
    • 数字化转型及运营业务线
    • 现代化企业、平台及云业务线
  • 合作伙伴
    • 概况
    • 汽车企业
    • 医疗企业
    • 公共服务机构
    • 清洁技术,能源与公用事业
    • 媒体和出版业
    • 零售业和电商
    • 金融和保险企业
    • 非盈利性组织
    • 旅游业和运输业
  • 洞见
    • 概况
    • 特色

      • 技术

        深入探索企业技术与卓越工程管理

      • 商业

        及时了解数字领导者的最新业务和行业见解

      • 文化

        分享职业发展心得,以及我们对社会公正和包容性的见解

    • 数字出版物和工具

      • 技术雷达

        对前沿技术提供意见和指引

      • 视野

        服务数字读者的出版物

      • 数字化流畅度模型

        可以将应对不确定性所需的数字能力进行优先级划分的模型

      • 解码器

        业务主管的A-Z技术指南

    • 所有洞见

      • 文章

        助力商业的专业洞见

      • 博客

        ThoughtWorks 全球员工的洞见及观点

      • 书籍

        浏览更多我们的书籍

      • 播客

        分析商业和技术最新趋势的精彩对话

  • 加入我们
    • 概况
    • 申请流程

      面试准备

    • 毕业生和变换职业者

      正确开启技术生涯

    • 搜索工作

      在您所在的区域寻找正在招聘的岗位

    • 保持联系

      订阅我们的月度新闻简报

  • 关于我们
    • 概况
    • 我们的宗旨
    • 奖项与荣誉
    • 多元与包容
    • 领导层
    • 合作伙伴
    • 辅助功能
    • 新闻
  • 联系我们
China | 中文
  • United States United States
    English
  • China China
    中文 | English
  • India India
    English
  • Canada Canada
    English
  • Singapore Singapore
    English
  • United Kingdom United Kingdom
    English
  • Australia Australia
    English
  • Germany Germany
    English | Deutsch
  • Brazil Brazil
    English | Português
  • Spain Spain
    English | Español
  • Global Global
    English
博客
选择主题
查看所有话题关闭
技术 
敏捷项目管理 云 持续交付 数据科学与工程 捍卫网络自由 演进式架构 体验设计 物联网 语言、工具与框架 遗留资产现代化 Machine Learning & Artificial Intelligence 微服务 平台 安全 软件测试 技术策略 
商业 
金融服务 全球医疗 创新 零售行业 转型 
招聘 
职业心得 多元与融合 社会改变 
博客

话题

选择主题
  • 技术
    技术
  • 技术 概观
  • 敏捷项目管理
  • 云
  • 持续交付
  • 数据科学与工程
  • 捍卫网络自由
  • 演进式架构
  • 体验设计
  • 物联网
  • 语言、工具与框架
  • 遗留资产现代化
  • Machine Learning & Artificial Intelligence
  • 微服务
  • 平台
  • 安全
  • 软件测试
  • 技术策略
  • 商业
    商业
  • 商业 概观
  • 金融服务
  • 全球医疗
  • 创新
  • 零售行业
  • 转型
  • 招聘
    招聘
  • 招聘 概观
  • 职业心得
  • 多元与融合
  • 社会改变
软件测试技术

3 misconceptions about BDD

Juraci Vieira Juraci Vieira
Nicholas Pufal Nicholas Pufal

Published: Dec 17, 2013

BDD has been often misunderstood among developers, QAs and even BAs. We often hear of teams saying that their project is using BDD, but when we check it out, it turns out to be using only a BDD tool for test automation - and not the BDD concepts itself. So in the end, we hear people arguing about the tools, and not about the ideas that inspired the creation of those tools.

The output of that is a bunch of complaints that we see in blogs all over the internet - people that start to reject the whole idea behind BDD, only because they have tried to use a tool without first changing their attitude towards software development.

We commonly hear of these top 3 complaints about BDD:

#1 The client doesn't care about testing

This is the most common complaint. It makes complete sense to state that, as what really matters for the client is software that suits the client’s purpose. Starting a discussion on testing somehow seems to give business people the green light to tune out their attention. Also the word testing unfortunately bears a negative connotation in the software development community.

But wait a second, we are talking about behavior driven development, and it has nothing to do with testing. Testing is something you can't do until the software exists. Test is verification, and here we are talking about specifications.

BDD is a design activity where you build pieces of functionality incrementally guided by the expected behavior. In BDD we step away from a test-centric perspective and go into a specification-centric perspective, meaning that this complaint was born misplaced.

#2 The client doesn't want to write the specifications

This is the second most used complaint. Let's break it down.

“The client must write the specifications by himself”

Whoever complains about this is assuming that the client is expected to propose a solution to his or her own problem - the very problem that your software was supposed to address.

If the client writes the specifications he won't benefit from something called cognitive diversity. Cognitive diversity comes from groups of heterogeneous people working together. For instance, he needs the advice of engineers that know the technical aspects of the problem that he wants to solve. He also needs a QA to spot edge cases that no one else noticed. Else, he may come up with a solution that is much more complex than it needs to be.

It's unfair to complain about something that we, as the development team, are supposed to help our clients with.

“The client needs to use the tool to write specifications”

Not really. What the client really needs to do is to provide to the team information about the problem that he wants to solve and together they come up with concrete examples to lead the development process.

#3 You can achieve the same without a business readable DSL

This argument is commonly found among developers. Most of these developers state that there is no real benefit in having this new “layer” - describing behavior in business readable language - as it only adds complexity and make the test suite slow.

If we take a look at this complaint when working on a Ruby tech stack, this usually implies that instead of using Cucumber, you can simply use Capybara + RSpec to achieve the same results with the benefit of having a faster test suite.

That’s like comparing apples with oranges: they are both completely different things.

The benefit of having a business readable DSL - such as feature files written using Cucumber in this case - has benefits beyond the nuts and bolts of development. It's not just about code; it's about improving the all-important communication within the team.

For instance, it's about having a BA collaborating with a developer and a QA, with all of them making improvements on that single file (the feature file) - which is a non-abstract way of presenting ideas for the software. Plus, they will be using their complementary cognitive capabilities to brainstorm together about the best path to transform a specification into fulfilled business needs.

A successful case using BDD

How complicated would it be for you to explain to a 3 year old child how a bank transaction works? The same challenge applies during software development, as the client domain can be sometimes pretty cloudy and vague to the delivery team.

We need examples to understand. Realistic examples are a great way to communicate, and we use them often without even thinking about it. Working with real world examples help us to communicate better because people will be able to relate to them more easily.

We can easily realize that when we are working on a complex business domain. A good example on that is a previous project we worked on. The company was an investment bank, and as expected in a domain like this, the terminologies were really complicated, making it hard for the developers to communicate with the BAs from the bank.

So, in an effort to communicate better, part of our process was to have a quick call with the BA before playing a card. This BA would then share with the developers, the feature file that he came up with, describing each of the concrete examples that he thought about.

As we didn't have any QAs in this team, it's important to mention that one of the developers in this session had to keep a QA mindset - trying to spot edge cases, improvements to the scenarios, etc. The other developer on the team would properly focus on the technical challenges to implement it, such as make suggestions to move a scenario to a code level specification, which offers a faster feedback. Everyone could also suggest changes to a scenario's step definitions, in order to make it more meaningful to everyone.

The benefit of having it is that the BAs increased their understanding on the technical challenges of the scenarios and the developers had a clearer idea of the business needs and therefore what really needed to be developed. Plus, whenever changes had to be done, having that single piece of information would make everyone on the team in sync about it.

Down the rabbit hole

To sum up, the main idea behind BDD is that it's driven to prevent communication gaps, that is having everyone in the team communicating more often, better and based on real world examples and not on abstract and imperative requirements.

We hope that this article helps to make people more aware of the benefits of BDD - and make it clear that tools are only something complementary to the full stack agile methodology that it actually is.

If you want to go deeper on the subject, we strongly suggest the following sources:

  • "Specification by Example" by Gojko Adzic
  • "The RSpec Book" by David Chelimsky
  • "The Cucumber Book" by Matt Wynne and Aslak Hellesoy
  • Dave Astels and Steven Baker on RSpec and Behavior-Driven Development
  • Gojko on BDD: Busting the Myths
Master
政策声明 | 现代奴役声明 | 辅助功能
Connect with us
×

WeChat

QR code to ThoughtWorks China WeChat subscription account
© 2021 ThoughtWorks, Inc.