I’m writing this article so individuals can see where they are on the BDD journey. Recognising where you are is important as it allows you to realise just how much further you can actually go.
I’ve been to another client site where I’ve been told they ‘are BDD’. I’ve seen it many times, and although the intention is good there is a difference between ‘being BDD’ and ‘BDD syntax’.
There seems to be a fair bit of confusion out there. I’ll attempt to keep this concise and simple:
You aren’t BDD if:
- You are operating in your own silo within the team e.g. Automation writing their test cases in BDD, separate from the rest of the team
- Your incoming stories/EPICs are not being written in a BDD format
- Your incoming requirements are prototyped/mocked screen shots by BA’s. This should come after your EPICS and should supliment your BDD stories
- BDD Syntax is mostly application specific, and not abstracted to a business level flow
BDD is about:
- About upfront story collaboration … Look up the Three Amigos
- Subjecting the requirements to rigour from development, test and PO stakeholders
- Investing time in the requirements phase of the project, making sure the project is building the right thing and hence spending less time coding against the wrong thing
- Driving out ambiguous requirements and gaining a shared team understanding of the problem to be solved
There is a difference between BDD syntax and ‘being BDD’. BDD syntax has its benefits, and it is a fundamental platform from which teams can grow.
The difference I see between BDD and TDD:
- BDD is about verification – Checking ‘Are building the right thing for the client?’
- TDD is about validation – Checking ‘Has the right thing been built to specification?’
If you are in the BDD syntax mode, you are likely to be checking against the specification. Particularly if you BDD language is application specific and not business abstracted.
Note: BDD is not a replacement for central business rules document, architectural designs or design mockups. It compliments them. These are still needed. Do not lock up your business rules into distributed BDD artefacts.
BDD Is About Requirements & Reducing Risk
If the requirements are wrong or ambiguous, then an exponential amount of time is spent codifying and testing the wrong thing. This is what BDD attempts to address. We spend a vast amount of time in projects coding (and then repairing) against the wrong thing. This is wasted effort.
BDD attempts to make sure you are building the right thing by investing team time understanding the requirements.
There is a decrease in risk of miscommunication and increased rigour if more members of the team are engaged in the requirements process. They can question, poke and firm up requirements and specification if they actually understand what the project is attempting to achieve.
This is a marked difference from waterfall – where stakeholders follow a document specification and are detached from the requirements process. This also has an increased risk around requirements quality when a large dependency is built on fewer people getting requirements correct.
There is also an individual/team cost to the waterfall process as well, that is lack of engagement, detachment from the greater goal and an over specialisation of role. BDD encourages and promotes the opposite.
So that is the difference I see between BDD Syntax and ‘Being BDD’. If your project is in a BDD Syntax mode realise and enjoy the rest of the journey. Be warned though – ‘Being BDD’ isn’t easy.