Behaviour Driven Development (BDD)
If you work in a software company, do you sometimes feel that your voice is not being heard by the software development team? Or if you are a software developer, do you feel you are not getting enough feedback from people in the business when you are developing your product?
In Panintelligence, our development team cares about receiving input from people in every part of the business. To avoid some of the problems mentioned, we have adopted Behaviour Driven Development.
Behaviour Driven Development (BDD) is a software development process to engage communication between the software development team and other parts of the business.
It adopts a simple but powerful format to document requirements and issues, called BDD specification, to enable consistent communication. The BDD specification format includes 3 main keywords: GIVEN, WHEN, THEN.
- GIVEN the preconditions
- WHEN an action happens
- THEN the expected results appear
For example, we can document software requirements for getting money out of a cash machine as below:
GIVEN the cash machine has a stock of cash AND the user has input the correct PIN number AND the cash amount to withdraw is less than the amount in the account WHEN they want to withdraw cash THEN the user should receive the cash AND the same amount of money in the account should be deducted from their balance.
You might say, hang on a second, the amount you withdraw should be less than the daily limit e.g. £300, regardless of how much is available in the account.
When you start having this type of conversation, you have already had an input into the software development process, and that’s the powerful part of Behaviour Driven Development.
The example provided above only contains one scenario of a story. Other scenarios may include:
- The account doesn’t have enough money
- The request is over the daily withdrawal limit
- The PIN number provided is incorrect
- We use the BDD at Panintelligence format to document requirements that have been clarified
- We don’t necessarily use BDD to document vague requirements, but the same conversation happens and we always have a better understanding by trying to adopt the BDD format
If you want to know more about documenting multiple scenarios for a story, please visit Wikipedia for more information about Behaviour Driven Development.
What really works for us at Panintelligence is having a conversation so that we can receive input from anyone who wants to be involved.
We then take the input into consideration when shaping our product requirements, clarifying issues, and talking about the design, and we gain quick and informative feedback from other parts of the business.