This is a trick question, right? In agile, everyone works on the same items together, at the same time. Yet, the reality is we’re not all interchangeable cogs. Developers and testers each bring their own, unique skills to the table. The key to effective agile is not minimizing our differences, but building upon the strengths each person brings to the team. Join us for this hands-on simulation and retrospective as developers and testers explore how agile teams build quality into their process, how each member contributes to that quality, and how we can avoid traditional testing pitfalls.

Why is testing so slow? Why is testing taking so long? We’ve done lots of things to speed up testing, but we still face this time crunch when we get to the end of the iteration; then we find out from the field that there are problems that we didn’t anticipate. In this workshop, we’ll gather familiar patterns that slow down testing, and discover a few more in the process—and maybe we’ll find that the slowest parts of testing have nothing to do with testing at all. If you have problems that you’d like to solve or solutions that you’d like to offer, come along.

So much of moving traditional test teams towards agile methods & testing is focused towards the individual tester and testing techniques. As often is the case in agility—directors, managers, team leaders and test-centric project managers are sort of marginalized. But not in this session! Here we want to focus on agile testing from the perspective of the Test Leader. We’ll pair off into groups and examine some of the greatest challenges when it comes to leading a testing team from traditional towards agile testing and emerge real-world strategies for surviving and thriving in agile testing.

Acceptance Tests elaborate a user story & are essentially behaviour specifications, expressing examples of how the application will actually be used. These should represent customer-intent in terms the customer understands.

This session shows developers and testers how to transcribe their understanding of customer intent in a way that makes sense to customers. Using the popular BDD Given/When/Then approach to acceptance tests, participants will learn how to leverage the popular Fit framework to replicate that approach. Alternatives to using Fit, including using code, will also be explored.

I’ve been on teams with way too little and (heresy) way too much testing. There have been lots of talks about how you should test more, but I’m going to dare to talk about when you should test less. Too much testing can lead to backlash, gridlock, morale problems, and poor velocity. Of course lack of testing can lead to bad design, gridlock, morale problems, and poor velocity. The level of testing a team can support depends on many factors including: team size, developer buy in, managerial approval, company size, IT support, and testing experience.

Nonfunctional Testing has always been ignored and neglected because no one is sure what to do with it. Agile environments make Nonfunctional Testing more difficult as people try to invent ways to make it conform to whatever they are using. The goal of this workshop is to define methods to integrate and maneuver nonfunctional testing into agile environments. We will discuss the current concepts and determine the How, What and Why of Nonfunctional Testing.

In this session, we’ll test some real small to medium size applications for quality and bugs. Through three main activities of collation, investigation and prediction, we’ll move through our explorations understanding applications then experimenting with discovery and failure situations, utilizing tools when relevant. While Erik will guide the session and explain the context, a large part of the testing will come from the audience, either as ideas or driving the keyboard. While this is accessible as an introductory session, it will also show how to perform industrial strength ET.

End-to-end tests appear everywhere: test-driven development, story-test-driven development, acceptance testing, functional testing, and system testing. They’re also slow, brittle, and expensive. In this expert-level workshop, we will discuss why end-to-end testing is used, examine where and why it breaks down, and generate more effective solutions. We will spark ideas for participants to explore further on their own.

We will not be debating the premise (that end-to-end tests are problematic). This is an expert-level workshop and attendees will be expected to participate fully.

This tutorial introduces the concept of playtesting - a central component of software development processes in the game industry - which is the process through which players inform the ongoing evolution of a game’s design. The importance of playtesting is derived from the fact that in the game industry, the quality of the software produced is measured in terms of the user’s subjective experience of it. In the tutorial the participants explore the benefits, pitfalls and relevance of playtesting for their business, be it a game company or any other software development operation.

An agile-tester needs to wear many different hats to be effective in their role. Sometimes they have the ‘Detective’ hat on, sometimes the ‘Scientist’ and others the ‘Police Officer’. Working in small groups we will create a taxonomy of the hats testers wear. Once a the list is produced we will then see which are the most common, enjoyable, frustrating, Agile and a number of other attributes.