It was a long time ago that I introduced UADD to an Agile audience in a Delhi NCR Agile conference (Here is the link to the presentation) but I still remember a few reactions like, "What is UADD? We have never heard of it". It told me a few facts of the world; technology, techniques and tools are not adopted as per requirement or need but on the basis of terminology that is popular, at least in India.
Almost ten years later (during which time not one in any project that I worked on was there a mention about BDD or UADD), I came across this project that used Gherkin, Cucumber and jest to drive a BDD + TDD project but the scenarios were not elaborated as tests, which is what you can do if you use jest-cucumber.
So, here we are, I thought to myself, a completely wired, end-to-end testing tool that I had envisioned a decade back using Slim and NUnit - the tools then were obviously lacking in many respects - to increase visibility of requirements as planned and to help tracking them as the project moves forward is popular.
This made me think that now is the time to take BDD to the next level.
BDD or Behavior Driven Development is a software development technique to address requirements in an easy-to-read, conversational description of a product feature and scenarios, with steps outlined, to help complete the realisation of the feature.
But BDD or rather its form, can also be used in a non-software development context.
For instance, there was this recent BBC review of a self-driven car of Tesla that showed how the auto-pilot in the Tesla could not detect a stationary car ahead of it and crashed right into it because another moving car ahead of the Tesla had been blocking it till it swerved away at the last moment.
This demonstrates the classic lazy testing syndrome - the positive scenarios are tested but the negative ones are not - often seen with teams that are pressed to deliver or does not have deep experience in testing a system
With the BDD language, you are provided with a mechanism to put the scenarios down on paper for better visibility and due to its language, in a conversational tone, proper communication happens across the system to convey what needs to be tested because when the behavior of the system is under test then the stakeholders range from business to laymen who do not understand the technical jargon.
Let me elaborate how BDD helps in the Tesla scenario
Scenario 1
Given the car is in auto-pilot mode,
When a stationary car is ahead (distance not mentioned in this scenario)
Then brakes should be applied or an alert should be sounded
Scenario 2
Given the car is in auto-pilot mode,
When a stationary car is ahead at a distance of 10 meters (distance mentioned in this scenario)
Then brakes should be applied or an alert should be sounded
Scenario 3
Given the car is in auto-pilot mode,
When a stationary car is ahead at a distance of 5 meters (distance mentioned in this scenario)
Then brakes should be applied or an alert should be sounded
Scenario 4
Given the car is in auto-pilot mode,
When a stationary car is ahead at a distance of 3 meters (and so on)
Then brakes should be applied or an alert should be sounded
BDD is about establishing a communication with all the stakeholders in the system under development. It is all about increasing collaboration between all the stakeholders including the customer.
In the above example, it is so clear that any inexperienced person in the team may conclude that scenario 1 is all that is needed and a little more experienced may conclude that the four scenarios completes it but not so.
The biggest anti-pattern when using BDD is to write the scenarios in isolation.
The four scenarios, especially from 2 - 4, highlight the fact that a base scenario of applying instant brakes when any object, stationed at any distance less than already tested for, from the self-driving car, completes the quality assurance required.
Almost ten years later (during which time not one in any project that I worked on was there a mention about BDD or UADD), I came across this project that used Gherkin, Cucumber and jest to drive a BDD + TDD project but the scenarios were not elaborated as tests, which is what you can do if you use jest-cucumber.
So, here we are, I thought to myself, a completely wired, end-to-end testing tool that I had envisioned a decade back using Slim and NUnit - the tools then were obviously lacking in many respects - to increase visibility of requirements as planned and to help tracking them as the project moves forward is popular.
This made me think that now is the time to take BDD to the next level.
BDD or Behavior Driven Development is a software development technique to address requirements in an easy-to-read, conversational description of a product feature and scenarios, with steps outlined, to help complete the realisation of the feature.
But BDD or rather its form, can also be used in a non-software development context.
For instance, there was this recent BBC review of a self-driven car of Tesla that showed how the auto-pilot in the Tesla could not detect a stationary car ahead of it and crashed right into it because another moving car ahead of the Tesla had been blocking it till it swerved away at the last moment.
This demonstrates the classic lazy testing syndrome - the positive scenarios are tested but the negative ones are not - often seen with teams that are pressed to deliver or does not have deep experience in testing a system
With the BDD language, you are provided with a mechanism to put the scenarios down on paper for better visibility and due to its language, in a conversational tone, proper communication happens across the system to convey what needs to be tested because when the behavior of the system is under test then the stakeholders range from business to laymen who do not understand the technical jargon.
Let me elaborate how BDD helps in the Tesla scenario
Scenario 1
Given the car is in auto-pilot mode,
When a stationary car is ahead (distance not mentioned in this scenario)
Then brakes should be applied or an alert should be sounded
Scenario 2
Given the car is in auto-pilot mode,
When a stationary car is ahead at a distance of 10 meters (distance mentioned in this scenario)
Then brakes should be applied or an alert should be sounded
Scenario 3
Given the car is in auto-pilot mode,
When a stationary car is ahead at a distance of 5 meters (distance mentioned in this scenario)
Then brakes should be applied or an alert should be sounded
Scenario 4
Given the car is in auto-pilot mode,
When a stationary car is ahead at a distance of 3 meters (and so on)
Then brakes should be applied or an alert should be sounded
BDD is about establishing a communication with all the stakeholders in the system under development. It is all about increasing collaboration between all the stakeholders including the customer.
In the above example, it is so clear that any inexperienced person in the team may conclude that scenario 1 is all that is needed and a little more experienced may conclude that the four scenarios completes it but not so.
The biggest anti-pattern when using BDD is to write the scenarios in isolation.
The four scenarios, especially from 2 - 4, highlight the fact that a base scenario of applying instant brakes when any object, stationed at any distance less than already tested for, from the self-driving car, completes the quality assurance required.
