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]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.

 

Syndication

 

Agile Testing Directions
Introduction
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects
Postscript

Permalink to this list

 

Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list

 

Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI

 

Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."

 

Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich

 

Where to Find Me


Software Practice Advancement

 

Archives
All of 2006
All of 2005
All of 2004
All of 2003

 

Join!

Agile Alliance Logo