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.
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.
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.
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.
Are you interested in learning more about this way of developing software? Join me in a two day course called BDD Kickstart in Stockholm.
RSS