Behaviour Driven Development

Behaviour Driven Development Live Virtual Class is designed to leave delegates more confident in five key areas:

1. Defining the problem: Why is it so difficult to communicate requirements remotely.
2. BDD scenarios: Specifying acceptance criteria with examples of behaviour.
3. Full-cycle product development: Where BDD scenarios fit.
4. Gherkin: how clear and concise scenarios can drive automated regression tests.
5. How to make it work remotely: practical collaboration across multiple locations.

Course Content

Building the wrong thing
We start by highlighting the challenges in delivering bespoke software that can be coded to behave however the engineers make it. The opportunities for misinterpreting requirements are huge, and we’ll hear examples from the trainer and the delegates of how requirements discovery can fall short.

BDD Scenarios: a solution to poorly understood requirements
Delegates will learn how to use BDD to reach agreement on how the product should behave in different scenarios. For example, should the login system allow you to try again if you entered the wrong password? How about if you’ve already tried four times? This course introduces the concept of scenarios structured as preconditions, actions and results. For example:

Given I have entered the wrong password four times, when I try again then I see an error message stating my account is locked.

Delegates will learn that these conversations bring assumptions to the surface that may be clarified before development takes place, and will apply this technique to a simple case study feature – creating a full set of BDD scenarios.

Using Scenarios to break down large features
A common problem for agile development teams is the pressure to break down items so that they are small enough to fit several items into a two-week cycle. It is easy for an agile coach to tell a team “you’ve got to break it down”, but sometimes it’s really hard for the engineers to actually do so in a meaningful way. Delegates will learn how to use scenario headings as a breaking point for large items, and will apply this technique to a large “epic” case study feature.

Gherkin
Gherkin is a name for the syntax or format of BDD scenarios. Delegates will build on the simple “given, when, then” format learned in previous exercises and explore the full range of options for developing clear and expressive scenarios:

• Feature files, documentation and scenario headings.
• Step definition files and options for test automation (overview – no coding involved).
• Scenario backgrounds, outlines and example tables.

This will be applied to a complex case study example that involves making some decisions about how the feature should work. Delegates may play the roles they normally play such as product owner, development team or test specialist, and then reflect on how and when they should do this back at the office.

BDD in context
The course wraps up with some hints and tips for using BDD effectively and some anti-patterns to avoid. A case study example will show that BDD is not just for simple web products, and we’ll review some examples of good practice for collaborating effectively and building a strong, sustainable technical approach.

Behaviour-Driven Development Outcomes

The whole group will leave with the confidence to collaborate effectively to plan, implement and verify software requirements. There will be supporting information introduced during the class that will help people to get started, and then to grow into more sophisticated techniques while being aware of common problems to avoid.