Find the slides of the talk here.

10 years ago, Dan North first came up with the idea of BDD: using examples in conversation to explore the behaviour of systems, then carrying those examples into code. Since then, we've learnt a lot about how BDD works, how it works best, and how it can fail horribly! Even the most experienced BDD practitioners have learnt a lot from their failures... but what were they? And how are we failing now?

For calculations the key examples are usually given as input-output tables that describe what expected calculation result the system should provide for the different input figures. As for these applications even small mistakes can quickly cause big losses, you better describe them in a way that both the business and the development team can understand them. In our projects most of the stakeholders use and like Excel for describing these and they are masters in doing this. Excel seems to be their DSL, so let's try to use it for generating automated tests!

You can find the slides of Gaspar's talk here

The tests that I see often remind me of a previous attempt to allow non-technical people to work with computers: Cobol. The features that helped to make it hugely successful, its "English syntax" and flat structure, are also barriers to abstraction and modularity--the techniques we need to cope with scale. Is writing everything out in full the only way we can get our point across?

The slides of the talk can be found here

A short time into our journey we started wonder if we were getting the benefits we originally envisaged.. With users still performing manual UAT, Audit still on our back, BA’s creating written procedure documents, and hundreds of tests written in an mix of styles…Clearly we weren't...

This talk will go through the issues we faced, the benefits we weren't realising, and how we changed to get the most out of the ATDD process.

This talk will show you how to be successful even with the oldest legacy projects out there through the usage of Agile processes and tools like Impact Mapping, Feature Mapping, Example Workshop, Story and Spec BDDs.

Along the way, they will ask a few questions:

• Don't the best BDD conversations come from diagrams, maps, and examples?
• How can we refactor our living document as easily as our code?
• Should we be asking non-devs to write in parseable language?
• How do we integrate our awesome TDD practice?

Pete and Phil will present some new tools for conversations that also readily translate into a highly usable living document that reports status and can be refactored easily.

In this session Seb will dissect a user story and find that they come in several shapes and sizes (that change throughout the project lifecycle). He will walk through the evolution of a feature file and see why so many of the text-book examples actually encourage bad habits.

By the end of this session, attendees will walk away being able to describe the multiple uses of user stories as well as understand that misuse is commonplace. They will learn to recognise the value of user stories, appreciate the strengths and weaknesses of typical user story templates, as well as having gained in depth knowledge of the relationship between feature files and user stories. We hope also that attendees will have learnt to identify the shortcomings of typical text-book feature file examples.

Hear how they used ATDD to better engage product owners in the development process, to build a ubiquitous language across the team, to promote faster feedback, and to create a team culture where technologists and product owners alike were deeply invested in the quality of every deliverable and in the system as a whole.

Learning Outcomes:

• How can Sam and Lav keep our teams ahead of the curve and focused on innovation? They like book clubs! Learn about the evolution of their version of ATDD, grounded in the team's lunchtime study of Domain Driven Design (Eric Evans) and Specification by Example (Gojko Adzic).
• How does the 'knowledge crunch' happen in a complex domain? How can they expand the capabilities of individual team members? ""Everyone's an Engineer"" - learn about their cross-pollination approach to roles - the team jettisoned the standard expectations for roles and had every team member doing things they might not typically do.
• ~1300 Acceptance Tests implemented In Process - the analytical, data driven nature of the domain made testing through the UI arduous. Learn about the different approach they took, where hidden elements, sleeps, and ajax calls were the least of our worries.
• Have you ever been on teams that employed 'non standard' practices? Welcome to the “Test Tent” - their transformation of the standard Test Pyramid into something useful for making s'mores. Learn about the unique challenges they faced as a result of our testing approach."

Learn how to

• apply recipes from the Cucumber Recipes book in a .Net environment

• automate tests in the ancient world of desktop apps depending on cameras, fingerprint readers and other physical devices

Come along to Manuel's session to realize that Cucumber Recipes can be cooked with C# as well. Without burning yourself. Most of the time.

Leading BDD expert and co-author of 'The Cucumber Book', Matt Wynne, will explore the post BDD team.

This live demo will cover following topic
- How BDD tools works with acceptance tests and Headless drivers
- Benefits of using Headless Drivers
- Introduction to PhantomJS & Zombie
- Up Cucumber+Capybara+Poltergeist - Setting up Behat+Mink+Zombie - Automating responsive websites with Headless drivers

This session was a hands on workshop and therefore not recorded*

You'll build a web application, and along the way we'll discuss how to structure your tests to keep them fast, reliable and valuable. You will also learn how to integrate Selenium WebDriver with Cucumber-JVM and how to set up a project in an IDE such as IntelliJ IDEA or Eclipse.

This session was a hands on workshop and therefore not recorded*

Impact Mapping helps teams collaborate to break down and prioritise scope into increments of business value and explore options as to how to deliver business capabilities in the shortest possible time frame.

Kicking off development in this way facilitates key buy in from business stakeholders on philosophies underpinning Agile and BDD practices, particularly flexible scope.

For development teams, Impact Mapping provides a unified vision and clear line of sight between features and measurable business benefits, hence driving delivery of lean software and ensuring teams are collaborating on the highest value examples.

By the end of this highly interactive session, participants will have gained hands-on experience of Impact Mapping and an understanding of how to apply this technique to maximise the effectiveness of other BDD and Agile practices in their organisation.

You can find the slides of this session here.

This session was a hands on workshop and therefore not recorded*

This session was a hands on workshop and therefore not recorded*

This session was a hands on workshop and therefore not recorded*

Step 1 is "Hunt the value". Step 2 is "Agile VSM" (VSM = Value Stream Mapping as Feature Injection was too obscure). Step 3 is "Break the Model". Step 4 is "User ROI" or improve the return on Investment to the User (or how does UX fit in this Agile stuff). This tutorial will cover Agile VSM and Break the Model, both of which were discovered to fit with the Given-When-Then format. He will briefly introduce "Hunt the Value" and "User ROI" but wont talk about them too much as he finds them a bit boring these days.

Chris had something to do with the Given-When-Then format but he can't really remember so he prefers to blame Dan North for everything. He writes about Real Options and IT Risk Management at theitriskmanager.wordpress.com and upsets people on Twitter using the handle @papaChrisMatts

This session was a hands on workshop and therefore not recorded*

So what's next?

In this unique tutorial we mix BDD with Cynefin, the sensemaking framework that helps makes sense of the world around you and the problems you encounter. Find out where BDD works... and where it fails. Use the patterns you already know... but at scale. Identify risk, embrace uncertainty, continuously improve and create glorious innovation - not just in software, but in the whole of your life!

(Please note that this tutorial focuses entirely on the conversational aspects of BDD, and does not touch automation or tools.)