BDD Overview
The goal of software development is to deliver products that meet requirements(business value). That’s what we are aiming to. But the fact is, business analysts(BA) and developers(Dev) think in different way normally, because BA define requirements from the perspective of the business goal while Dev implement the software in code detail. At this point, Behaviour Driven Development promote communication amoing BA and Dev to collaborate with the aim of delivering products with business value.
BDD uses examples to illustrate the behaviour of the system that in a readable and understandable language for everyone, creating a common understanding and surface uncertainty to deliver software. These examples describe the scenarios that how customers use the software, which form the features of the software. In BDD, features are the key throughout the development.
BDD in scrum team
In the whole, we apply BDD in the following way.
At the beginning of a sprint, BA would deliver the business goal to us in the upcoming sprint, and have a meeting with scrum team for product backlog refinement, so that everyone knows what should be delivered in the new sprint and their priotiries. Usually BA write down requirements with User story, and append Acceptance Critieria(AC). Everyone could ask any questions if he is unclear of the detail or have doubt on logic while BA explain user story and AC. Therefore, this is a process to clarify requirements and meet common understanding on them.
After the refinement meeting, we translate user stories into scenarios. Scenrios are examples to illustrate how user would do step by step with the software. Gherkin is a preffered language to write scenarios, because it could be easily understood by BA, QA and Dev. And besides it could be used as feature file in the tool we adopt, Cucumber. Below is an example of feature file.
Feature: log on
As a user, I want to log on the hsbc mobile app, so that I could get online service.
Scenario: log on with correct username and password
Given I open the hsbc log on page
When I input username and password and submit
Then I could see home page with my account
...
Scrum team discuss all scenarios together and raise uncertainty within scenarios to BA for explanation and confirmation. Therefore, they dive deeper into the requirements and details.
As scrum team are clear of requirements, they start to estimate the time they need for development. As they consider how to implement the requirement, they are constructing the structure of code to get a more precise estimatation for the implementation and testing. Planning Poker is better choice for estimation but for present we still let the developer estimate their own tasks. This is what we could improve in the future.
Everyday we have a stand-up meeting to update task status before we start our work. The meeting could share scrum team’s current work and issues to each other, which promote communication in the team.
During the sprint, we implement automation testing as we have clarify all requirements. We write automation scripts based the feature files generated at the beginning of the sprint. More over, we set up Continuous Integration(CI) for development. When the developer push their code to github, the CI will check out the source code, build package and deploy to testing environment and run automation script to validate the system. Therefore, developer could get quick feedback about their commit.
Advantages and disadvantage
With BDD, the communication in scrum team is promoted and developer could get quick feedback from automation test and CI. But there are disadvantages either. On occasions you have to write as many automation script as source code, which is not a small budent for scrum team.