Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Tue, 03 Jun 2003

Why Ruby?

Bret writes why he favors Ruby for testing training and testing tasks.

Full disclosure: I had something to do with Bret's enthusiasm for Ruby.

## Posted at 20:50 in category /ruby [permalink] [top]

Agile Fusion

Agile Fusion is an event that Rob Mee and I have organized. We're bringing together context-driven testers and agile programmers to build product together and learn from each other. We'll be doing it next week, starting the 11th, at James Bach's very nice tech center in Front Royal, Virginia.

I'll be blogging it, as will others, I bet. The main purpose of this note is to lay out what we'll be doing, to set a context for the blogging. But first, a side note:

Our goal was to have around two programmers for each tester. Unfortunately, our programmers have been hit by a wave of bad luck: two have had management changes of heart, one has developed a medical problem that prevents travel, and one has been laid off. So we've drifted away from our ratio. (Testers seem immune to bad luck.)

We've been inviting people through word of mouth, but I'd love to add a couple more programmers at this last minute. If you are such a person - good programmer, inclined to agile methods, interested in the intersection of testing and programming, likes to pair program, generally plays well with others, and can make it to Virginia at short notice, drop me a line (marick@exampler.com). There's no charge, other than your share of expenses - we're trying to break new ground, not make money.

Here's a version of the original invitation I sent out.

Catch phrase: learning by doing, then talking

Deliverable: a better idea of XP/agile testing in the heads of the participants, who can then take that back to their company, their clients, and other events (notably the XP/AU XPFest). People will be prepared to do more than they could before, and they'll be ready to take the next step in learning.

Mechanism:

We will do two parallel XP projects with very short iterations. One will work with legacy code (Dave Thomas's RubLog) and the other will start from scratch (implementing a prototype replacement for the software used by the American College of Veterinary Internal Medicine for the large animal patient management section of the examination for board certification).

The software will be written in Ruby. We should have enough Ruby experts to help out those who are novices, but people should learn a little Ruby before coming.

The projects will differ from run-of-the-mill XP projects in that there are three novel testing components.

1. Many of the pairs will have self-identified testers in them. This person will suggest test-first tests from a tester perspective. My desired goals:

   • The programmer will incorporate into his habits tests of a type he hadn't considered before. With luck, we'll elaborate on the notion of elaborative tests, which is like-but-different to conventional testing notions of bug-finding tests.

   • The tester will realize which of his habits are inappropriate in an XP context.

2. Iterations will be driven not just by stories and their attendant conversation, but also by customer tests first. We will, through doing, learn various things about how that can be done:

   • what kind of tests best drive programming?

   • when should they be produced?

   • what's a good format? (alternately: what are the details of working with FIT?)

   • how should people collaborate on tests?

   • how do tests fit in with the planning game?

   As with the programmer testing, I really hope that both XPers and testers have "Aha!" moments in which they come to doubt some of their habits and assumptions.

3. We will carve out a space for manual exploratory testing. Through doing it, we'll come to a better understanding of how it might fit in an XP project.

The XP projects will last from 9-3 each day. 3-5 will be spent on a mini-retrospective about what happened that day. People will talk about what they did, what lessons they drew from it, and suggest things we might do the next day.

Those two hours might lead to testers asking for exercises or lectures about some aspect of XP. They might lead to programmers asking for exercises or lectures about some aspect of testing. Those could happen in the evening. Or, if people don't want that, they can happen during the day.

Commentary

That's my starting agenda. I'll be disappointed if it's not modified pretty radically over the week. I will push, however, for keeping the focus on learning through building product.

Leaving aside those specific goals, it is fundamental to my conception of this workshop that we all intend to push outside our comfort zone. As I've said ad nauseum, I don't believe "agile testing" will be a straightforward extension of either context-driven testing or XP-style test-driven development. Rather, I should say I hope it won't be.

## Posted at 14:20 in category /agile [permalink] [top]