Testing is a cornerstone within the burgeoning discipline of Extreme Programming. Much has been written about XP, but to date, no book has specifically addressed the key role that the tester plays in this lightweight methodology. This new book defines how an XP tester can optimally contribute to a project, including what testers should do, when they should do it, and how they should do it. Each teaching point is supported by practical examples, helpful suggestions, and proven techniques that will help readers improve the quality of their next project. The material is based on the authors' real-world experience making XP work within development organizations. The book also provides a unique "Road Hazard Survival Kit" with copious resources that help the tester address common pitfalls. Both testers unfamiliar with XP, and XP devotees unfamiliar with testing, will benefit greatly from this book.
Click below for Sample Chapter(s) related to this title:
Sample Chapter 2
I. THE XP TESTER ROLE.1. An Overview.
II. TEST DRIVE THROUGH AN XP PROJECT.
This is a book about being a tester on an Extreme Programming (XP) team. It plugs a gap in the currently available XP materials by defining how an XP tester can contribute to the project, including what testers should do, when they should do it, and how they should do it. We are writing it because we think that XP is a better way to develop software and should be used by more teams. We believe that an acknowledged place in XP teams for testing and quality assurance will help bring that about.
Our goals in this book are to:
We hope that if you are not currently using XP, that you can influence your own organization to try it. Even if your team uses some other process for software development, we think you can apply "extreme testing" practices to add value.
Because not everyone will be familiar with XP, we provide an overview of the basic concepts in the introduction, and describe a few aspects in more detail as necessary throughout the text. But this will be a bare-bones summary, at best, and there are several excellent books on the subject, as well as a wealth of information on the Web.
The book is divided into three major parts:Part I - The XP Tester Role
This is where we define what we think the tester role is (and is not), how a project will benefit from it, what is in it for the tester, and generally why XP needs a tester role.Part II - The XP Test Drive
Here we go through an XP project step by step and suggest what goals to shoot for, which activities to engage in, and helpful techniques to try as a tester on an XP project.Part III - Road Hazard Survival Kit
Finally we provide some resources to help you cope when the real world doesn't conform exactly to the ideal XP project. Large projects, for instance, where an XP team is imbedded in a larger, non-XP effort, or when critical XP practices are modified or omitted.
We've tried to keep the things as practical as possible, and provided real-life examples as well as exercises for you to try it out for yourself. The exercises are built around an XP project to develop a simple web-based tracking application, and we provide portions of the application at various stages for you to practice on.
We think you will find this book helpful if you are already a member of an XP team, or if you are a testing/quality assurance professional, or if you are in any software development role and considering XP.
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
Click below to download the Index file related to this title: