CoDers Who Test

CoDers Who Test - Afternoon Conference

At CoDers Who Test we will focus on tackling one of the most important aspects of successful Continuous Delivery pipelines : Just how should we go about automating our testing procedures to align with our DevOps and Continuous Delivery frameworks?

The conference will feature a series of talks for a whole afternoon. Come and discover how adopting best practices and better tooling can get your Continuous Delivery pipelines flowing like never before!

To get ready for the conference and make the most out of it, you can also choose to attend additional workshops. More details about the different ticket options is available below.

Pre-conference morning workshops

BDD Vitals – Writing better BDD scenarios by Gáspár Nagy

Behavior Driven Development is an agile development technique that improves collaboration between technical and non-­technical members of the team, by exploring the problem using examples. These examples then get turned into executable specifications, often called ‘scenarios’. The scenarios should be easy to read by all team members, but writing them expressively is harder than it looks!

In this half-day workshop you will learn how to write expressive BDD scenarios. We’ll start by giving you a very brief introduction to BDD/ATDD. Then we discover where the BDD scenarios come from: how to structure the requirements and illustrate them with examples, so that the team has a shared understanding about what the expected behavior is.

The examples will be turned into scenarios then. But how? You’ll then be introduced to different writing styles by reviewing pre­pared scenarios. And obviously, you’ll get a chance to write your own scenarios based on examples that we’ll bring along.

We’ll be using Gherkin, the syntax used by Cucumber and SpecFlow ­ but you won’t need a computer. And, you’ll leave with a checklist of tips that you can use the next time you sit down to write a scenario.

Testing in Continuous Delivery and DevOps by Emily Bache & Samuel Ytterbrink

DevOps is about creating a culture where everyone is aligned towards the goal of helping the business to win. Continuous Delivery is a big part of achieving this. You need a great deal of automation in the development process: build, deployment, monitoring, and of course test automation. Having said that, manual testing is not an optional extra, and testing skills are really valuable in the development team. In fact, testing is a central activity for making the whole process work.

In this workshop we’ll mix theory with hands-on exercises, examining the place of testing in Continuous Delivery. It’s a chance for you to explore where you could put testing activities in a deployment pipeline. We’ll talk about how to optimize the pipeline design and discuss what metrics you could use to monitor it.

One-day training course by Dave Farley on May 14th

Introduction to Continuous Delivery

This course is designed to introduce participants to the fundamentals of Continuous Delivery. The content ranges from introductory to expert-level and from senior management level, to in-depth technical detail.

The course includes 3 modules, and each module is a mix of presentations, workshops and interactive sessions.

Fundamentals 1: CD is widely seen as “state-of-the-art” in software development. CD changes the economics of software development. This module provides a strong rationale for why CD works. It describes the CD approach and why it works, comparing CD with other approaches. This is the value proposition for the approach.

Fundamentals 2: At its most fundamental CD is about enabling businesses to become more experimental, to learn and adapt to change. Why is this important? What does it take? How does that impact your business? How does this affect the way in which teams work?

Acceptance Testing: Acceptance testing in CD helps the team focus on the value that stories deliver to users. This module describes the qualities of effective Acceptance tests, provides an approach to designing tests as “Executable Specifications” for the behavior of a system that are robust in the face of changes to the system-under-test. This is a technical module at the level of software design with a few simple code examples.