Behavior Driven Development Training Course

Audience, pre-requisites and assumed knowledge

The intent of BDD is that it is a tool that bridges the gap between technical and business people, and this course is designed with that audience in mind. Typical attendees include:

• Business representatives, subject matter experts, product owners and business analysts, who have a clear understanding of the requirements they want to see developed.
• Engineers, software developers, manual and automated testers, who have the expertise to implement the requirements needed.
• Teams who want to find a better way of agreeing requirements and avoid re-work that arose through assumptions and misunderstandings.
• Teams who are interested in starting the path towards automating their time-consuming manual regression tests.
• Experienced BDD practitioners who are about to help the other delegates in the class to apply BDD, and want to help establish an agreed approach.

The focus of the class is in helping to bridge the gap between the business and IT. This is not a deep-dive technical class to teach specific test-automation frameworks options such as Cucumber, Specflow, Behat and jBehave, but these will be highlighted and put into context if desired.

Approach

We are a friendly team of practitioners and we like to provide a personal level of support, before, during and after the class:

• Pre-course reading designed to expose questions so that they can be explored in class.
• Contact details allowing delegates to ask questions to the trainer before and after the class.
• Access to a comprehensive set of guidance after the course so that delegates apply what has been learnt.
• Digital course effectiveness surveys with results sent out to delegates and sponsors straight after the class.

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.

Behavior-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.