Foreword


As I see it, I have two jobs to do in this foreword. The first is to persuade you that it's worth your time to keep reading this book. The second is to place the book in context: what does it say about the world of testing and about how that world is changing?

My first job is easy. The reason is that the book you're holding is both skimmable and eloquent. Stop reading this foreword. Go to Part II. Browse some chapters. Do you see tidbits you can put to immediate, practical use on an XP or agile project? That's a sign Lisa and Tip are writing from experience. Do the chapters seem to hang together into a coherent testing strategy? That's a sign they've thought about their experience. Is the tone flexible, avoiding dogmatism? That's a sign that you'll readily be able to adapt what you read to your local circumstances. These are the things that make the book worth reading. Don't believe me; check for yourself.

The second job is harder. How does this book fit in? As I write (May 2002), the world of testing seems stuck. We're all supposed to know certain fixed concepts: what the purpose of testing is, what the relationship of testers to programmers should be, what test planning means. When presented with a new project, it seems we're intended to take those concepts as givens, follow some methodology, and fill in the blanks through a process of top-down, stepwise refinement.

But that's not really what happens, at least not on good projects. The tester comes to a project equipped with a hodgepodge of resources: concepts, attitudes, habits, tools, and skills some complementary, some contradictory. She begins by modeling her new situation after one she's experienced before. She applies her habits and skills. She keeps what works and changes what proves awkward. She fluidly adapts any of her resources to the situation. In her project, testing goes through what Andrew Pickering calls "the mangle of practice" (in his book of the same name).

All this is hidden, because it's disreputable in at least two ways. First, everything is up for grabs, including those seemingly fixed concepts we're all supposed to know. The practice of testing, when applied in specific contexts, changes the purpose of testing, the relations of people, what test planning means. There's precious little solid ground to stand on. Second, the trivial can be as important as the lofty. Knowing how to use 3 x 5 cards well may matter more than knowing test design techniques. Unthinking work habits may have more effect than reasoned decisions.

We need to make the mangle respectable. It's harmful when people feel vaguely ashamed of doing what has to be done. It's even worse when they don't do it because they think they must follow the rules to be "professional."

And that marks this book's significance beyond simply (!) helping XP testers. In it, you can see the traces of two people interactively adapting their practice of testing to a new sort of project, arriving at last at a point of stability: something that works well enough that they can gift it to others. It's an inspiring example. I mean that literally, in that I hope it inspires you to model your testing after it, run that model through the mangle of practice, and report back to us, saying, "Here. Here's what I do. Here's what I've seen. Here's what works for me. Try it."

Brian Marick
Champaign, Illinois
May 2002



Testing Extreme Programming
Testing Extreme Programming
ISBN: 0321113551
EAN: 2147483647
Year: 2005
Pages: 238

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net