Member-only story
BDD inside-out adoption strategy
The obvious, but overlooked, strategy to adopt BDD that is brilliant and really successful.
A well adopted BDD can make a difference. By sharing the same example —also called Scenario—, the three same roles share the same view of the software that is being developed. It makes the difference because, well applied, it reduces misunderstandings, do-overs, and useless features. It is by focusing on doing the right functionality, rather than doing the functionality right.
The classical BDD adoption strategy
The classical strategy is teaching the three main roles to collaborate through the Gherkin. Business learns to write the scenarios, developers translate them to code, and QA to validate them. But in this adoption there is a common problem: Gherkin is a programming language and business does not know how to code.
Starting business writing the Gherkin has a secondary effect: developers usually see business as an indisputable authority. Therefore, developers do not have the courage to help business to fix scenarios. QA has more success in that, somehow they see the Gherkin as the quality test, and they have the final word about quality.
And that is the concern. The developers are the only ones that are capable to deal with a programming language correctly, but they are too busy and too intimidated to make advance the adoption.
In the classical strategy, the adoption fails and ends in one of two possibilities: the BDD stops, or the BDD continues in a suboptimal state, and never reaches its fully potential.
In the classic approach, because developers are often busy coding, QA team members come out to help business in the writings. That is wrong because the main objective of BDD is Development –the last D — , not Quality.
The inside-out BDD adoption strategy.
This strategy is so obvious, that I do not know how we all fail to notice it.
BDD was created as a need from the developers, rather than from business or QA teams. It starts as an evolution of TDD, a tool for developers, in which the developers themselves, making the tests more readable…
