Hiya! Here are the talks from CukeUp! AU 2015. The conference played host to some great presentations and there should be something of value for everyone in here.

We're running the conference in Sydney again on November 17th-18th 2016. Tickets are now sale..

Find all our upcoming events on our website.

Without further ado:

BDD might just be software development nirvana. But what lies beyond? What happens when a team get really, really good at BDD? Can you get so good you don't need it anymore? Let's find out.

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.

Behaviour Driven Development is a powerful collaboration technique that can empower teams to deliver higher value features to the business faster and more effectively. But although Behaviour Driven Development is based on a number of simple principles, it can go dramatically wrong in a myriad of different ways.

In this talk we discuss twelve BDD anti-patterns we frequently encounter in real-world BDD projects, anti-patterns that can dramatically reduce the effectiveness of BDD as a practice, and that can even cause BDD adoption to fail entirely. Looking at everything from insufficient collaboration practices to poor use of test automation tooling, from teams that test too much to teams that forget the most important scenarios, we will look at the many different ways that BDD can go wrong, and how it should be done.

We will use real-world examples to illustrate each of these anti-patterns. You will learn how to spot these issues in your own projects, and more importantly how to avoid them in the first place.

Sharon will discuss how the various teams she has worked with in the past have integrated quality into the way they are working by using simple and easy process and mindset changes to maximise the quality of their products. She will cover the ideas of code/test ownership, manual testing by developers, cross team ownership of the solution and true understanding of "quality" from the beginning of the work cycle.

Behaviour Driven Development has been touted for many years now as the one and only way to develop tested (and testable) software. However, we have found that this approach is not a “one size fits all” solution, and can fail teams in many cases. Nasty test retrofits, scope creep, and additional bottlenecks are all ways in which BDD can throw your beloved project under the bus, without improving the quality of your work one iota.

What, then, is the future of BDD? Taking the time to assess the behaviour of a team itself can often drive the way that team does development, so by moving our view of BDD from development practice to team working practice, we can help teams mature in a way that works for them - and for their end product. We would like to take you on this journey with us by providing some insights into ways that we have seen BDD pass and fail in different teams.

Automated acceptance tests/executable specifications are a key part of sustainable software delivery, but most teams struggle to implement these in an efficient, productive way without hindering velocity. Alister will share a few ways to move towards successful automated acceptance testing, and many traps of automated acceptance testing, so you achieve business confidence of every commit in a continuous delivery environment.

*Note: talk may or may not include 500 don’ts

Prescott’s Pickle Principle: "Cucumbers get more pickled than brine gets cucumbered." No matter what automation you use, cucumber (if you use it for testing), selenium, ultimately good test design helps you decide what to automate and what NOT to automate. What makes good test design? This principle is about ethics and autonomy.  It tells us that it can be challenging to preserve independent thinking when you deal with a large and important client.  Recent corporate scandals show that even legal counselscan get "pickled" in the corporate "brine."

Though all teams work differently at ustwo, depending on what works best for them and the context of their project, there’s a workflow that’s becoming popular for projects that result in product delivery. Within this workflow, how we do BDD is something that’s evolved rapidly and has become integral to the way we work not only internally, but also with our clients (who often fulfil the product owner role).

Of course the workflow I reference above is the outcome of a great deal of trial and error, and it’s this journey that I’d love to share with everyone, with a strong focus on collaboration (especially between disciplines) and the role BDD plays within that.

What you’ll get from this session is insight on our journey and learnings towards building teams and processes that have resulted in products people love.

This will be a non-technical talk.

This session will be a lighthearted look at how testing and BDD have commonly been grouped together, why they continue to be (by supposed gurus), why it is a problem and what we can do about it. In this session you will learn how to separate the two and why it will be better for everyone in the long run.