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

Mon, 30 Jun 2003

The agile context

The noble premise of context-driven testing is that the tester's actions should be tailored to a particular project. The premise of the Agile Alliance is that certain projects have enough in common that they deserve a common name: "agile". It follows that those common themes should drive the actions of context-driven testers on agile projects.

But describing that commonality is a vexing question. The Agile Manifesto is an early attempt, still the definitive one. But, in my own thinking, I find myself coming back to different themes, ones more related to personality and style than values and principles.

Now, it's presumptuous of me to define Agility: although I was one of the authors of the Manifesto, I've always thought of myself as something of an outsider with a good nose for spotting a trend. So when I make pronouncements about Agility, I look for approving nods from those who I think get it more than I do. In recent weeks, I've gotten them from Michael Feathers, Christian Sepulveda, Jeremy Stell-Smith, Ward Cunningham, and Lisa Crispin.

Made bold by them, I present a partial and tentative list of what I'm calling Things Agilists Want to be True. I'm calling it that to avoid arguments about whether they are or are not true. Truth is irrelevant to whether those beliefs are part of the agile context.

• A team of generalists trumps a team of specialists.

• To get the best work out of programmers, protect them from distractions and interference. Instead, let them do what they think is best. The Scrum literature is the most clear on this point.

• Tests are a tool for guiding design and making change safe. They are only secondarily about finding bugs, primarily about facilitating steady, smooth progress. (Ward once said to me, apropos unit tests, "Maybe we shouldn't have used the word 'test'.") Although this belief is strongest in XP, I sense that it's becoming common agile knowledge.

• Every program contains a better, cleaner, more capable program that wants to get out. That better program is released when customers provide a well-paced stream of change requests to programmers who respect their craft.

• As Lisa Crispin puts it: "On an XP team, if you ask for help, someone has to help you." At Agile Development Conference, I was surprised by how often the word "trust" came up. It was sure a heck of a lot more often than it does at testing conferences.

Of what use is this list? Well, I'm going to use it to remind me to think about my habits. Suppose I'm a specialist tester on an agile team. Being a specialist is comfortable to me - it's been my job many times - but I have to remember it cuts a bit across the grain of an agile project. I'll have to think more about earning - and giving - trust, about offering help outside my specialty, about taking care that my bug reports don't disrupt the smooth steady flow of improvement. Otherwise, I'll be wrong for my context.

My hunch is that many testers will find the team dynamics of an agile project their biggest challenge.

## Posted at 17:21 in category /context_driven_testing [permalink] [top]

FIT Fest

Along with Ward Cunningham, Bob Martin, Micah Martin, and Rob Mee, I'm hosting FIT Fest at XP Agile Universe. It's all about test-first customer-facing tests using Ward's FIT framework. Do join us.

One of the ideas of the event is that we'll give people a chance to use FIT to build solutions to commonly-posed problems. I collected a few at Ward's FIT tutorial at Agile Development Conference. For example, one was expressing tests that drive GUIs. Feel free to send me more.

## Posted at 09:53 in category /testing [permalink] [top]

Christian Sepulveda's oscillating testers

New blogger (and great guy) Christian Sepulveda has an interesting idea for how to do testing on agile projects. I think he's finding a way of being inclusive (though I don't know if that was part of his specific intent). Some testers are most comfortable being vigorous finders of mistakes. And those testers often emphasize coverage (in the broad sense: use of a well-thought-through testing model of the system/domain/failure space/etc.).

I, in contrast, want to extend test-first programming to the whole product. That makes testing about design, only indirectly about finding mistakes. I emphasize incremental progress and "just in time" testing. I accept the increased risk of gaps in coverage that comes with that (and concede that I'm making it harder to know how often and how far and in what ways a tester needs to step back and think comprehensively about the problem).

But suppose the team has testers of the first sort? Suppose it needs testers of the first sort? How should they be integrated into the work? Agile projects have some tricky differences from conventional projects - an emphasis on steady forward "flow" that batches of bugs can disrupt, a greater dependence on trust between members of different interest groups (most notably between programmers and customers, but also between programmers and testers), a programmer-centricity that a skeptic would think of as coddling, and so forth. I see in Christian's proposal ideas for integrating testers of the first sort while maintaining what's different about agile projects.

## Posted at 08:29 in category /agile [permalink] [top]