Behavior Driven Development (BDD) and Agile
As mentioned earlier, BDD is a technique that uses language, not a spreadsheet-like format. As your user stories follow a certain cadence ("As a _______, I want to _______, in order to _____ "), BDD has a certain cadence for acceptance criteria. That cadence is summed up in the following:
There are many tools your team can use to implement the executable part of this acceptance criteria. These tools include, but are not limited to Cucumber, rSpec and SpecFlow. These tools allow you to take that cadence mentioned above and hook that scenario into your code.
Once again, the actual acceptance criteria can be written in collaboration with other team members. The story is pulled to be worked on. The team then gets together, developers, QA, product managers, etc., and they collaborate on the scenarios that are needed to ensure the story is done. In other words, when these criteria are met, the team is confident that the story is done.
Just a note to exercise a little caution here not to be too inflexible with this definition of done. There have been times when a product owner sees the story completed according to this specification, and the story meets acceptance criteria. The product owner sees a demo of the "done" story, and the result is not what she expected, but is considered "done" by those criteria. At this point, if the team has shown this prior to the end of a sprint, the product owner may ask to tweak the story a little. If the team is okay with that tweak, they can just fix it and the acceptance criteria along with it. This feedback loop helps the team deliver a more valuable product to the customer.
Remember these acceptance criteria are helping us to have conversations within the team. How the above scenario is handled should be up to the team.
In BDD, the user story starts with the business reason first. This is the main difference between our story shown in the FitNesse example and this story. BDD asks for this, since the business reason should inform us why we are doing this story.
- In order to capture sales from nonmembers.
- As a non-frequent traveler member visitor to our website,
- I want the non-member to be able to browse the hotel properties and be able reserve them.
The Acceptance Criteria in BDD style for this story could be something like this:
- Given a first-time visitor to Eric Hotels website
- When I access the reservations page
- Then I see a "Frequent Traveler Registration" button.
- Given I am a visitor to Eric Hotels website
- And I am a member of the frequent traveler program,
- When I login as Eric
- And my Password is 123
- And I click login
- And I access the reservations page,
- Then I cannot see a "Frequent Traveler Registration" button.
These scenarios could be placed on the back of story cards or entered into your tracking tool. Most importantly they can now be placed into your code, ensuring the executable part of this article! In a tool like Specflow, the above scenarios could be copied and pasted as a test, and hooked up to code to test.
One of the benefits of the BDD tools is that they are clients that run along with the development environment. This makes it easy for developers to run the tests right away on their computers. With a server tool like FitNesse, developers need to compile code, copy to a server, run it there, make changes back on the developer computer. The BDD tools are a little more convenient for developers.
Figure 2 shows a screenshot of how the Acceptance Criteria looks in the tool SpecFlow.
Click here for larger image
Figure 2. Specflow example of what BDD looks like in IDE
Ensuring Continuity of Executable Acceptance Criteria
Put these tests into your continuous integration to ensure that your teams continue to make changes to the acceptance criteria later in the life of the software. This helps your Agile development team with documentation of requirements. That is what makes the "executable" part of executable acceptance criteria so helpful.