BDD represents behavior-driven development. BDD helps teams focus efforts on identifying, understanding and building features that delivery business values. BDD also suggests to documentation for features in up-to-date and executable manners.
Focus on business values
BDD pushes the team focus on delivery business values rather than doing tickets or tasks. From the beginning of defining requirements, business analyst, development team and QA team gather to talk about expectations from the business owner, what are valuable to the business and what features can help to delivery these values. These features are then broken down into smaller features which can be deliveried within one sprint. In order to let all stackholders collaborate effectively business values and features are written down in specifications with concreted examples using a natural and structured language called Gherkin language.
Up-to-date specifications
Specifications get updated whenever there are recent requests. As in traditional development, specifications are stored in a wiki, confluence or a content management system. Whenever a change occurs, a ticket is created; and changes are described in the ticket, later on updated to existing specifications. Sometimes, the ticket owner forgot to update to specifications documents, even though changes are already reflected into the newest release. This is because there aren't any constraints between the implementation and specifications. On the other hand, in BDD, specifications always reflect the newest implementation. Each specification does not describes feature in details but also include confirmations of done. If all of these confirmations are passed, it means the feature is already implemented.
Executable specifications
To enforce the specification up-to-date, specifications documents remain not only the place to describe features but also an executable document to verify existing implementation. If features are describe in wiki page, we can only manually run the features verify whether they are implemented, or whether they are completed correctly. This manual process could be boring and costly if it has to be repetitive. In contrast, BDD specifications are executable to verify recent changes. These documents contain features definitions and clarified by scenarios which are in turn become more specifically by concrete examples. Each scenario plays as an automation test case and concrete examples are inputs for this test case. With these executable specifications, at anytime, everyone can identify all features, comprehend how these features perform and catch up the progress of implementing features.
Conclusion
Behavior-driven development is quite interesting and very beneficial to apply for software development process. It helps team focus to delivery valuable features and catch up the implementation activities through up-to-date, executable specifications.
