Acceptance tests have become a common part of building software for an agile process. However, I've observed a trend of growing build times - with teams saying "Our build is 15 minutes... well, actually it's 45 minutes because our Cucumbers took so long, so we parallelized the cukes." One reason for this may be that teams treat their acceptance tests as "Write-Once": create for a new story, get them to pass, and leave them be. In this talk we'll explore the technical and social forces that cause an acceptance test suite to grow, and discuss some ways to refactor and improve these tests. We'll touch on hexagonal architecture, declarative vs. imperative style, and alternate Cucumber step implementations.

Which details should we leave visible, and which should we hide? We’ll look at ways to distill our scenarios down to their essence, and remove distracting incidental details.

Many times, when people complain about something Cucumber’s not good at, they’re unwittingly describing something Cucumber shouldn't be good at. They’re revealing that they don’t quite understand BDD and Cucumber’s role in it.

Cucumber is the world's most misunderstood collaboration tool and people need to hear this over and over again.

Have you ever had thoughts like:

• I'm going to lock my customers in a room and make them type gherkin until their heads bleed
• I've given the developers EXACTLY what the app should do. Why are they still talking to me?
• FIFTEEN Scenarios! For a log in form??!?
• We need 6 people to spend 6 hours detailing a feature we MIGHT implement?

Let's talk about a few ways to build shared understanding and why our techniques tend to break down as the product evolves.

Expect no vicar waffle, only the truth about implementing BDD on an agile digital studio and the state of BDD tools for mobile devices.

Acceptance Test Drive Development (ATDD), Behavior Driven Development (BDD), and Cucumber promise many things related to your User Story acceptance tests. They promise tighter collaboration between the Product Owner and the team. They promise the ability for the Product Owner and other stakeholders to be able to "write their own" executable acceptance tests. They even promise an increase in the value being produced by your teams efforts as they focus on building the "right" products.

But promises are promises and not always tied to reality. Join experienced Agile Coach and QA Leader Mary Thorn as she explores 3 distinct case studies of implementing BDD in real world environments. Mary will explore each in detail, showing you how she introduced ATDD/BDD tooling and practices. How far was she able to advance towards the above promises, what were her strategies and how she overcame resistance. If you're struggling with or hoping to introduce BDD, this session will help you develop your own strategies and prepare your for the challenges.

Leading BDD expert and co-author of 'The Cucumber Book', Matt Wynne, will explore how a team evolves as they learn BDD. You’ll recognise pain-points you’ve felt yourself, discover the ones in your future, and get inspired about how far your team could get.

I will also cover the notion of a SpecFlow gateway, with which one can achieve end-to-end testing with a variety of devices as an orchestration mechanism for broader tests.

Many start using Cucumber as a testing tool, but fail to realize its true value as a team collaboration tool. What essential team skills might be lacking?

If you are wondering why your team is struggling to put BDD into practice, perhaps they lack crucial skills they need to succeed with BDD, and may not even know it. Or if your team is doing BDD but unable to take it to the next level, what is missing?

This workshop explores critical, but often overlooked, skills teams need to practice and master in order to move forward in their BDD journey.

This workshop is open to all those operating in software - developers, testers, BAs, products owners all welcome!

You will learn how to:

• Get to the heart of a problem domain quickly, so you can focus on solving the most important stories and scenarios first.
• Distinguish between rules and examples.
• Write examples that help you deduce the rules.
• Write scenarios that communicate with various stakeholders: business stakeholders, auditors, future testers and programmers, customer support.