Audience

Primarily testers and developers who will be working on an agile team. Business analysts, XP “customers” and Scrum “Product Owners” would also benefit from attending.

Duration

2 Days

Agenda

Introduction

We reveal why traditional software development and testing is so painful, and review the very basics of Agile in order to introduce the “Agilists’ Dilemma”. We will also take a cursory look at how the tester’s role changes on an agile team. The first exercise, selecting a fictional project and writing up a few stories, sets the stage for all further exercises.

Painful Software Debts

We will describe how even an Agile project can generate and accumulate hidden (but very real) debt through manual testing, defect-tracking, and poorly crafted software.

Test-First as Just-In-Time Analysis

We explain “test-first” and how this allows for improved feedback for developers, testers, and stakeholders. It also alters the tester’s roles, responsibilities, and view of the software. We explore how to consider testing in detail before the software exists, and emphasize “acceptance” in the term “acceptance testing.” The next exercise gives us the opportunity to reexamine and split our stories in terms of two questions to be asked and answered by testers: “Can we get it tested during the iteration?” and “How will I test this story?”

Acceptance Test Driven Development

We describe Test-Driven Development, and compare and contrast the two types of TDD. We will briefly explore the types of automation, and their pros and cons. Fit is introduced as an example which provides incomparable simplicity and flexibility, allowing us to expand our concepts of good testing.

Your Testing Tool

We will discuss the chosen tool, the test formats available, the editors available for test-writing, and the underlying technology (at a very conceptual level).

For example, if you select FitLibrary, we start with the three basic forms of Fit tests, and then explore the enhancements made by Rick Mugridge, and his intent behind these enhancements. We examine a demo project with functioning code and tests. This is often the “aha!” moment (seeing is believing).

You will write your own tests on posters, and the team will evaluate the posters and consider options for enhancement.

Implementing Tests

Parallel exercises will give testers a chance to incorporate feedback into their tests, while developers work to set up at least one computer system with the tool installation and programming environment.

Organizing Tests

A brief discussion of how to organize your tests will quickly lead us into the next exercise: Writing at least one of our tests on the demo platform, and seeing what it does.

Translators

We show how to develop a Fit “Fixture” or Cucumber “Scenario” (for example), a small bit of code that connects the test to the system under test. Although this section is technical, it’s important for testers and developers to understand the give-and-take that is necessary to get the written test to “line up” with the translator. These bits of code are very easy to write, expand, and reuse, but the process may require some modifications to the test, itself. The exercise will pair up at least one developer and tester (potentially in a “fishbowl” environment, with the whole class observing), and the developer will use an IDE to build the translator. The classroom team’s goal is to see at least one test “fail successfully.”

How ATDD Works on an Agile Team

We talk about what would come next, if this had been an actual project. We review how an agile team uses ATDD during an iteration, and where and how collaboration takes place. We discuss the dynamic and incremental nature of test maintenance and reusable translator development. We will also discuss ways to adopt ATDD and the tool of choice, and to pay down technical debts in a measured, realistic fashion.”