What does BDD really stand for?

Filed under: BDD, Cucumber, Executable specification, — Tags: Behaviour-Driven Development, Gherkin — Thomas Sundberg — 2018-04-17

BDD is the acronym for Behaviour-Driven Development. It is a way to describe the behaviour of a system and a way to make sure that it is developed to behave as it should.

BDD is used for understanding what to create and for verifying the result.

Business-Driven Development

But BDD could also be the acronym for Business-Driven Development. BDDers work really hard to bridge the communication gap between development and business. We really try to involve the business people in the development. We value their input and love discussing concrete examples describing what the system should do. How it is done is less important when understanding what really matters for the business. Focusing on the what and not the how is a differentiator between communicative developers and regular developers.

Conversations and concrete examples

We communicate by having conversations and drawing on whiteboards or paper. These conversations are documented using concrete examples in a language we call Gherkin. It is a human readable, plain text format with minimal structure. It has some structure so it is possible to use for more than reading. It is a format that solves two problems. It solves a communication problem and it solves an automation problem. Business people don't care about the automation. They care about the service offered to the customers.

An example looks like this:

  Scenario: Deposit money in a savings account
    Given that Thomas has a savings account with the balance of 2500 USD
    When he deposit 200 USD
    Then his savings account should have the balance 2700 USD

This example describes a business problem with a concrete example. It isn't really interesting unless you are a bank customer. If you are a customer, then you would expect that this simple example describes an actual behaviour. You would really like the deposit function to work. The bank would be rather useless if it didn't.

Anyone can read and understand well written Gherkin. Readability is crucial for our most important readers, the business stakeholders. They are the most important readers because they are the ones with real domain knowledge. They know when a concrete example is correct and when it isn't. They help developers build the right thing.

Another name

If the business stakeholders are our customers, we could call this way of working Customer-Driven Development, CDD. That wouldn't fit the acronym we are using today. But it is a good name that describes what we want. It describes that we are striving for developing the right thing together with the business.

Learning more

Are you interested in learning more about this way of developing software? Join me in a two day course called BDD Kickstart in Stockholm.



(less...)

Pages

About
Events
Why

Categories

Agile
Automation
BDD
Clean code
Continuous delivery
Continuous deployment
Continuous integration
Cucumber
Culture
Design
Executable specification
Gradle
Guice
J2EE
JUnit
Java
Linux
Load testing
Maven
Mockito
Pair programming
PicoContainer
Presentation
Programming
Public speaking
Quality
Recruiting
Requirements
Scala
Selenium
Software craftsmanship
Software development
Spring
TDD
Teaching
Technical debt
Test automation
Tools
Web
Windows
eXtreme Programming

Authors

Thomas Sundberg
Adrian Bolboaca

Archives

Meta

rss RSS