A wise man (narcissist me) once said, “Life is all about the question and answers. The trick to a meaningful life is, To ask the right questions to yourself, so you can get on the right path to search for the answer.” The very first question one should always ask oneself is WHY.
Let's discuss our WHY in the current case.
Why BDD
Let's take a step back and start with the well-known software development practice TDD (Test-Driven Development). In TDD, the very first thing developers do is, set up the technical expectations from the code by writing failing test cases. After the expectation is set, the code is written/modified to finally pass all of the failing tests. It's an Acceptance driven development strategy.
TDD works fine to create a robust technically working product. But the whole TDD approach revolves only around technical teams. It barely involves the business analysis or product owners to validate the business aspect of a feature, they get involved only after code completion.
During development, sometimes the technical team misunderstands the real business needs and sometimes the business teams take incorrect assumptions about the technical team. Due to this miscommunication, we can end up with a technically functional product that does not meet the actual business asks.
This is when Behavior-driven development (BDD) comes to the rescue.
What is BDD
BDD is a software development approach, which brings business & technical teams together, to create a shared understanding of the requirements through collaboration. Teams communicate together and decide What the system should do in a specific scenario with a specific condition. And create behavioral test cases.
NOTE: BDD doesn’t concentrate on, how the system should do what it needs to do. BDD is just about what the system should do in a given situation. How part is covered by TDD.
BDD process has three phases — Discovery, Formulation & Automation
Discovery phase
First, Product Owner creates stories or features with Acceptance Criteria. Then technical and business teams collaborate and discover additional acceptance criteria.
Formulation phase
This phase refines the generic acceptance criteria created in discovery-phase, by formulating exact scenarios with detailed acceptance tests. The output of this phase is an illustrated system behavior in ubiquitous language.
Automation phase
Here is the actual groundwork happening, where developers/testers convert the formulation phase output to actual code. This ensures that throughout the project lifetime the system works as defined by the business.
This was a very brief summary of BDD.
BDD is a process, which provides an opportunity to create application behavior tests from both technical & business perspectives. How to write those tests, is still open to the framework and/or technology that developers decide to choose. In the next post Cucumber & Gherkin, we will discuss one such framework.
Comments