Register your product to gain access to bonus material or receive a coupon.
Testing Extreme Programming
- By Lisa Crispin, Tip House
- Published Oct 25, 2002 by Addison-Wesley Professional. Part of the XP Series series.
Book
- Sorry, this book is no longer in print.
Description
- Copyright 2003
- Dimensions: 7-3/8" x 9-1/4"
- Pages: 336
- Edition: 1st
- Book
- ISBN-10: 0-321-11355-1
- ISBN-13: 978-0-321-11355-9
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.
Sample Content
Online Sample Chapter
Downloadable Sample Chapter
Click below for Sample Chapter(s) related to this title:
Sample Chapter
2
Table of Contents
Foreword.
Preface.
Acknowledgments.
I. THE XP TESTER ROLE.
1. An Overview.Introduction.
Overview of XP.
Communication.
Simplicity.
Feedback.
Courage.
How XP Solves Testing and Quality Assurance Problems.
System and Acceptance Testing Resources Wasted on Unit- and Integration-Level Bugs.
Missing and Out-of-Date Requirements.
Huge Gaps between the System and User Expectations.
Wolves in Sheep's Clothing.
Summary.
2. Why XP Teams Need Testers.
Definition of Tester.
The Tester's Contribution, Illustrated.
Shun the Dark Side.
Summary.
3. How XP Teams Benefit from Having Testers.
Checks and Balances.
Acceptance Tests versus Unit Tests.
Navigating for XP Projects.
Summary.
4. XP Testing Values.
Communication.
Simplicity.
Feedback.
Courage.
Summary.
5. Overview of the XP Tester Role.
XP Tester's Bill of Rights.
XP Tester Activities.
Summary.
6. Quality and XP.
Defining Quality.
Setting Quality Criteria.
Who Is Responsible for Quality?
Summary.
II. TEST DRIVE THROUGH AN XP PROJECT.
7. User Stories and Release Planning.
The Tester's Role in Up-Front Activities.
Goals of Up-Front Tester Activities.
Summary.
Exercise 1.
8. Identifying Hidden Assumptions.
A Process for Finding Hidden Assumptions.
Example 1.
Summary.
Exercise 2.
Introducing the XTrack Application.
9. Defining High-Level Acceptance Tests.
Basic Acceptance Test Definitions.
Example 2.
Example 3.
Summary.
Exercise 3.
10. High-Level Acceptance Test Estimates.
Ways to Estimate Acceptance-Test Effort.
Quick-and-Dirty Approach.
Example 4.
A More Detailed Estimating Method.
Example 5.
Summary.
Exercise 4.
11. Enabling Accurate Estimates during Release Planning.
Why We Care about Estimates.
How You Can Improve Estimate Accuracy.
Summary.
Exercise 5.
12. Planning the First Iteration.
Overview of Iteration Planning.
The Tester's Role in Iteration Planning.
Thinking of All the Tasks.
Enhancing Communication.
Summary.
Exercise 6.
13. Defining and Estimating Testing and Test Infrastructure Tasks.
Identifying and Estimating Test Infrastructure Tasks.
Identifying and Estimating Functional and Acceptance Testing Tasks.
A Note on Separate Test Teams.
Example 6.
Test Infrastructure Tasks.
Acceptance Testing Tasks.
Summary.
Exercise 7.
14. Acceptance Tests and Quality.
Acceptance Test Details.
Internal and External Quality.
Summary.
Exercise 8.
15. Nailing Down the Details.
Picking the Customer's Brain (and the Programmers'!).
The Good, the Bad, and the Ugly.
Example 7.
Optional Tests.
Getting Creative.
Lights-Out Test Design.
Summary.
Exercise 9.
16. Writing Acceptance Tests.
Executable Tests.
If You Have Trouble Getting Started.
Summary.
Exercise 10.
17. Organizing Acceptance Tests.
Version Control of Acceptance Tests.
Executable Test Files.
Organizing Acceptance Tests in Spreadsheets.
Summary.
Exercise 11.
18. Test Design and Refactoring.
Establishing the Initial System State.
Tests That Leave the System State Unchanged.
Coupling between Tests.
Summary.
Exercise 12 130
19. Manual Tests.
Summary.
Exercise 13.
20. What!?!!
Manual Tests Are Unreliable.
Manual Tests Undermine the XP Testing Practice.
Preface
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:
- Convince current XP practitioners that there is a valid role for a tester on the team
- Convince testing and quality assurance professionals that XP offers solutions to some of their worst problems
- Convince both groups that the testers are needed just as much as in an XP project as in a traditional development project
- Provide enough detail and practical example to allow you to either perform the XP tester role yourself or work productively with a tester on your team, whether you are an XP newbie or veteran, tester, programmer, guide, customer, or manager
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 RoleThis 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 DriveHere 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 KitFinally 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.
0321113551P06272002
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 MarickChampaign, Illinois
May 2002
Index
Click below to download the Index file related to this title:
Index