BDD has gain popularity among many Agile shops in past few years. It has helped teams to work more collaboratively and with focus on end user expectations and business goals.
BDD with ubiquitous language gives the power to business and development teams to define the tests in business domain language. The Give…When…Then format let's you write the tests in readable english.
Given I am a registered user
When I enter my credentials
Then I am on the user account page
Above scenario gives a very clear picture of the tests intent without diving into the underlying technology and tools used.
BDD framework gives the testing team an opportunity to provide their inputs to the story even before the development is kicked off. QAs can write BDD scenario before the story with Product team which can then be used for automation tests. This establishes a very cohesive model where acceptance criteria are translated into a well functioning feature drive by BDD scenarios. It proves to be very successful as the automation of the features is done right with the development and the QA cycle doesn't lags behind the development cycle. BDD scenarios bridges the gap of documentation, lack of which is mostly feared by big organisations while adopting Agile. It covers for both requirements and manual tests which are difficult to maintain and often loose their worth in long running and big projects.
BDD framework gives the testing team an opportunity to provide their inputs to the story even before the development is kicked off. QAs can write BDD scenario before the story with Product team which can then be used for automation tests. This establishes a very cohesive model where acceptance criteria are translated into a well functioning feature drive by BDD scenarios. It proves to be very successful as the automation of the features is done right with the development and the QA cycle doesn't lags behind the development cycle. BDD scenarios bridges the gap of documentation, lack of which is mostly feared by big organisations while adopting Agile. It covers for both requirements and manual tests which are difficult to maintain and often loose their worth in long running and big projects.
Given the wide acceptance of BDD in projects, frameworks are available for most of the popular technologies used, here are the few popular ones :
Hi Mona,
ReplyDeleteAs a developer, I find that the biggest benefit of using BDD is that it helps me think through my design and solution much better than I would otherwise. Instead of just thinking about code, I also think about what the end user wants. Do you think developers would still get this benefit if the QA team wrote the BDD scenarios instead, and not the developers? - pat shaughnessy
Hi Pat
ReplyDeleteI think writing BDD tests should not be the sole responsibility of either the QA team or the developers instead should be a team ownership. With my experience the best thing that works for the agile teams using BDD is QAs and Devs pairing while writing down the basic BDD scenarios before starting the development. Then devs can modify the scenarios as the story progresses and when done QAs can write the negative and edge case scenarios. Product people can give inputs as and when required but I haven't seen them ever writing tests or reviewing them.
-Mona