Product Description

“As Agile methods have entered the mainstream, we’ve learned a lot about how the testing discipline fits into Agile projects. Lisa and Janet give us a solid look at what to do, and what to avoid, in Agile testing.”
—Ron Jeffries, www.XProgramming.com

“An excellent introduction to agile and how it affects the software test community!”
—Gerard Meszaros, Agile Practice Lead and Chief Test Strategist at Solution Frameworks, Inc., an agile coaching and lean software development consultancy

“In sports and music, people know the importance of practicing technique until it becomes a part of the way they do things. This book is about some of the most fundamental techniques in software development—how to build quality into code—techniques that should become second nature to every development team. The book provides both broad and in-depth coverage of how to move testing to the front of the development process, along with a liberal sprinkling of real-life examples that bring the book to life.”
—Mary Poppendieck, Author of Lean Software Development and Implementing Lean Software Development

“Refreshingly pragmatic. Chock-full of wisdom. Absent of dogma. This book is a gamechanger. Every software professional should read it.”
—Uncle Bob Martin, Object Mentor, Inc.

“With Agile Testing, Lisa and Janet have used their holistic sensibility of testing to describe a culture shift for testers and teams willing to elevate their test effectiveness. The combination of real-life project experiences and specific techniques provide an excellent way to learn and adapt to continually changing project needs.”
—Adam Geras, M.Sc. Developer-Tester, Ideaca Knowledge Services

“On Agile projects, everyone seems to ask, ‘But, what about testing?’ Is it the development team’s responsibility entirely, the testing team, or a collaborative effort between developers and testers? Or, ‘How much testing should we automate?’ Lisa and Janet have written a book that finally answers these types of questions and more! Whether you’re a tester, developer, or manager, you’ll learn many great examples and stories from the real-world work experiences they’ve shared in this excellent book.”
—Paul Duvall, CTO of Stelligent and co-author of Continuous Integration: Improving Software Quality and Reducing Risk

“Finally a book for testers on Agile teams that acknowledges there is not just one right way! Agile Testing provides comprehensive coverage of the issues testers face when they move to Agile: from tools and metrics to roles and process. Illustrated with numerous stories and examples from many contributors, it gives a clear picture of what successful Agile testers are doing today.”
—Bret Pettichord, Chief Technical Officer of WatirCraft and Lead Developer of Watir


Testing is a key component of agile development. The widespread adoption of agile methods has brought the need for effective testing into the limelight, and agile projects have transformed the role of testers. Much of a tester’s function, however, remains largely misunderstood. What is the true role of a tester? Do agile teams actually need members with QA backgrounds? What does it really mean to be an “agile tester?”

Two of the industry’s most experienced agile testing practitioners and consultants, Lisa Crispin and Janet Gregory, have teamed up to bring you the definitive answers to these questions and many others. In Agile Testing, Crispin and Gregory define agile testing and illustrate the tester’s role with examples from real agile teams. They teach you how to use the agile testing quadrants to identify what testing is needed, who should do it, and what tools might help. The book chronicles an agile software development iteration from the viewpoint of a tester and explains the seven key success factors
of agile testing.

Readers will come away from this book understanding

• How to get testers engaged in agile development
• Where testers and QA managers fit on an agile team
• What to look for when hiring an agile tester
• How to transition from a traditional cycle to agile development
• How to complete testing activities in short iterations
• How to use tests to successfully guide development
• How to overcome barriers to test automation

This book is a must for agile testers, agile teams, their managers, and their customers.

---

Product Details

• Amazon Sales Rank: #21021 in Books
• Published on: 2009-01-09
• Original language: English
• Number of items: 1
• Binding: Paperback
• 576 pages

Features

• ISBN13: 9780321534460
• Condition: NEW
• Notes: Brand New from Publisher. No Remainder Mark.
• Click here to view our Condition Guide and Shipping Prices

About the Author
Lisa Crispin is dedicated to helping agile teams and testers discover good ways to deliver the best possible product. She specializes in showing testers and agile teams how testers can add value and how to guide development with business-facing tests. Since 2003, she’s been a tester on a Scrum/XP team at ePlan Services, Inc., and frequently leads tutorials and workshops on agile testing at conferences. Lisa regularly contributes articles about agile testing to publications such as Better Software magazine, IEEE Software, and Methods and Tools. Lisa also coauthored Testing Extreme Programming (Addison-Wesley, 2002) with Tip House.

Janet Gregory is the founder of DragonFire, Inc., an agile quality process consultancy and training firm. Her passion is helping teams build quality systems. Since 1998, she has worked as a coach and tester introducing agile practices into both large and small companies. Her focus is working with business users and testers to understand their role in agile projects. Janet is a frequent speaker at agile and testing software conferences, and she is a major contributor to the North American agile testing community.

Excerpt. © Reprinted by permission. All rights reserved.

Preface

We were early adopters of Extreme Programming (XP), testing on XP teams that weren’t at all sure where testers or their brand of testing fit in. At the time, there wasn’t much in the agile (which wasn’t called agile yet) literature about acceptance testing, or how professional testers might contribute. We learned not only from our own experiences but from others in the small agile community. In 2002, Lisa co-wrote Testing Extreme Programming with Tip House, with lots of help from Janet. Since then, agile development has evolved, and the agile testing community has flourished. With so many people contributing ideas, we’ve learned a whole lot more about agile testing.

Individually and together, we’ve helped teams transition to agile, helped testers learn how to contribute on agile teams, and worked with others in the agile community to explore ways that agile teams can be more successful at testing. Our experiences differ. Lisa has spent most of her time as an agile tester on stable teams working for years at a time on web applications in the retail, telephony, and financial industries. Janet has worked with software organizations developing enterprise systems in a variety of industries. These agile projects have included developing a message-handling system, an environmental-tracking system, a remote data management system (including an embedded application, with a communication network as well as the application), an oil and gas production accounting application, and applications in the airline transportation industry. She has played different roles—sometimes tester, sometimes coach—but has always worked to better integrate the testers with the rest of the team. She has been with teams from as little as six months to as long as one-and-a-half years.

With these different points of view, we have learned to work together and complement each other’s skill sets, and we have given many presentations and tutorials together.

Why We Wrote This Book

Several excellent books oriented toward agile development on testing and test patterns have been published (see our bibliography). These books are generally focused on helping the developer. We decided to write a book aimed at helping agile teams be more successful at delivering business value using tests that the business can understand. We want to help testers and quality assurance (QA) professionals who have worked in more traditional development methodologies make the transition to agile development.

We’ve figured out how to apply—on a practical, day-to-day level—the fruits of our own experience working with teams of all sizes and a variety of ideas from other agile practitioners. We’ve put all this together in this book to help testers, quality assurance managers, developers, development managers, product owners, and anyone else with a stake in effective testing on agile projects to deliver the software their customers need. However, we’ve focused on the role of the tester, a role that may be adopted by a variety of professionals.

Agile testing practices aren’t limited to members of agile teams. They can be used to improve testing on projects using traditional development methodologies as well. This book is also intended to help testers working on projects using any type of development methodology.

Agile development isn’t the only way to successfully deliver software. However, all of the successful teams we’ve been on, agile or waterfall, have had several critical commonalities. The programmers write and automate unit and integration tests that provide good code coverage. They are disciplined in the use of source code control and code integration. Skilled testers are involved from the start of the development cycle and are given time and resources to do an adequate job of all necessary forms of testing. An automated regression suite that covers the system functionality at a higher level is run and checked regularly. The development team understands the customers’ jobs and their needs, and works closely together with the business experts.

People, not methodologies or tools, make projects successful. We enjoy agile development because its values, principles, and core practices enable people to do their best work, and testing and quality are central to agile development. In this book, we explain how to apply agile values and principles to your unique testing situation and enable your teams to succeed. We have more about that in Chapter 1, “What Is Agile Testing, Anyway?” and in Chapter 2, “Ten Principles for Agile Testers.”

How We Wrote This Book

Having experienced the benefits of agile development, we used agile practices to produce this book. As we began work on the book, we talked to agile testers and teams from around the globe to find out what problems they encountered and how they addressed them. We planned how we would cover these areas in the book.

We made a release plan based on two-week iterations. Every two weeks, we delivered two rough-draft chapters to our book website. Because we aren’t co-located, we found tools to use to communicate, provide “source code control” for our chapters, deliver the product to our customers, and get their feedback. We couldn’t “pair” much real-time, but we traded chapters back and forth for review and revision, and had informal “stand-ups” daily via instant message.

Our “customers” were the generous people in the agile community who volunteered to review draft chapters. They provided feedback by email or (if we were lucky) in person. We used the feedback to guide us as we continued writing and revising. After all the rough drafts were done, we made a new plan to complete the revisions, incorporating all the helpful ideas from our “customers.”

Our most important tool was mind maps. We started out by creating a mind map of how we envisioned the whole book. We then created mind maps for each section of the book. Before writing each chapter, we brainstormed with a mind map. As we revised, we revisited the mind maps, which helped us think of ideas we may have missed.

Because we think the mind maps added so much value, we’ve included the mind map as part of the opening of each chapter. We hope they’ll help you get an overview of all the information included in the chapter, and inspire you to try using mind maps yourself.

Our Audience

This book will help you if you’ve ever asked any of the following excellent questions, which we’ve heard many times:

• If developers are writing tests, what do the testers do?
• I’m a QA manager, and our company is implementing agile development (Scrum, XP, DSDM, name your flavor). What’s my role now?
• I’ve worked as a tester on a traditional waterfall team, and I’m really excited by what I’ve read about agile. What do I need to know to work on an agile team?
• What’s an “agile tester”?
• I’m a developer on an agile team. We’re writing code test-first, but our customers still aren’t happy with what we deliver. What are we missing?
• I’m a developer on an agile team. We’re writing our code test-first. We make sure we have tests for all our code. Why do we need testers?
• I coach an agile development team. Our QA team can’t keep up with us, and testing always lags behind. Should we just plan to test an iteration behind development?
• I’m a software development manager. We recently transitioned to agile, but all our testers quit. Why?
• I’m a tester on a team that’s going agile. I don’t have any programming or automation skills. Is there any place for me on an agile team?
• How can testing possibly keep up with two-week iterations?
• What about load testing, performance testing, usability testing, all the other “ilities”? Where do these fit in?
• We have audit requirements. How does agile development and testing address these?

If you have similar questions and you’re looking for practical advice about how testers contribute to agile teams and how agile teams can do an effective job of testing, you’ve picked up the right book.

There are many “flavors” of agile development, but they all have much in common. We support the Agile Manifesto, which we explain in Chapter 1, “What Is Agile Testing, Anyway?” Whether you’re practicing Scrum, Extreme Programming, Crystal, DSDM, or your own variation of agile development, you’ll find information here to help with your testing efforts.

---

A User Story for an Agile Testing Book

When Robin Dymond, a managing consultant and trainer who has helped many teams adopt lean and agile, heard we were writing this book, he sent us the user story he’d like to have fulfilled. It encapsulates many of the requirements we planned to deliver.

---

Book Story 1

As a QA professional, I can understand the main difference between traditional QA professionals and agile team members with a QA background, so that I can begin internalizing my new responsibilites and deliver value to the customer sooner and with less difficulty

---

Acceptance conditions:

• My concerns and fears about losing control of...

---

Customer Reviews

A much needed book. A must read.

"Agile Testing" is an excellent and must-needed book related to testing in agile product development. Much has been written about test-driven development on unit level, however, little has been written on higher level testing and the role of testers and test departments in Agile development. This book changes that!

The book consists of 6 parts. The first part if an introduction, the last part is a summary. The introduction starts with a short explanation of agile testing and then followed by the ten principles of an Agile Tester. One of the key messages in this book is "the whole team approach", meaning that testing should be within the team and should not just be "the testers job". Anyone in the team can test, however, teams will probably still benefit from having a test specialist of a test expert. This mindset is one of the key thoughts the book repeats over and over again. In the last chapter, the authors summarize their thoughts with the seven key success factors for testing. Again, "the whole team approach" is #1. The agile testing mindset -- the proactive, creative cooperative mindset as opposed to a quality policy mindset -- is the second success factor.

The second part of the book describes organizational challenges. In my opinion, this part was perhaps the most needed. In many organizations testers struggle to find their role on agile product development. The chapter relate to cultural change, team logistics and transitioning typical processes. I thought the chapters were enlightening. Parts I liked were the discussion about the change in role for QA managers and especially the experience that, without proper coaching, a lot of traditional testing people might simply flee your agile development effort.

The third part of the book takes Brian Maricks four testing quadrants and explains these in details. These quadrants describe the different types of testing and how they would happen in agile development. The unit testing part is not covered thoroughly, as the authors (correctly) mention that this is covered well by other literature. The higher-level functional (acceptance) testing is covered well, including advise on automation. Exploratory testing is also covered in detail and explains its role in agile development clearly. Non-functional testing is covered reasonably well, especially considering that this depends so much on the type of product you are developing.

The fourth part of the book focuses more on test automation. I didn't find much new information in here, though it was a good summary of modern test automation and some of the challenges and difference between traditional test automation.

Part five follows an agile tester though an agile project and explains for every step in an agile project what the role of an agile tester is. It starts with the role in release planning and estimating. Then it explains the preparation before an iteration (product backlog refinement) and how early example tests can (should) be written. It continues with iteration planning and then the actual activities an agile tester would do during the iteration. This part also includes the important discussion related to the use of bug tracking systems. The part ends with the iteration review/retrospective and some final works about the actual delivery.

As mentioned, in my opinion, a good book on agile testing was absolutely needed. And the authors do not disappoint at all. Their knowledge about the subject is obvious. They have put much effort in sharing actual experiences by the many sidebox experience sharing stories. They touch the seldom touched parts related to organizations and roles and transitioning. Their writing is clear, though sometimes repeats itself (but not so that it is annoying). Not much topics are left unanswered, the book is thorough.

All in all, this book is exactly the kind of book that was needed. I'd recommend it to anyone interested in agile development and especially testers who have a hard time finding their new roles. Great work! Five stars.

Great book, long overdue
The main theme of this book is fitting testing tasks into agile projects, and as such this book really is long overdue. Most agile books are written by programmers for programmers, leaving testers in particular to fend for themselves. No wonder why so many of them feel lost in this world. This book definitely delivers on the promise to ease the transition for testers and QA engineers who suddenly found themselves on an agile project. It has a testing focus and presents things in a way that testers, coming from more traditional process oriented software projects, should understand. The key pillars of practice on which the content of this book stands are improved communication, the whole team approach, agile testing quadrants and automation, so the book efficiently points traditional testers to new knowledge and ideas that they need to focus on to contribute to an agile project. It also provides a solid framework for executing traditional testing tasks in an agile environment without lagging behind the development and causing the project to fall into the "mini-waterfall" trap.

I would also recommend it to project managers and team leaders as they will be able to see the project from the testers' eyes and complement their knowledge about quality on agile projects. As such, it is especially an important reading for teams that consider JUnit the extent of their "testing" process. The book raises valid concerns about commonly overlooked tasks such as test planning, security, performance and usability testing, documentation testing and provides some very practical advice how to plan and execute exploratory testing efficiently.

Great help for transitioning QA analysts to Agile teams
I'm a QA Manager in a department of 30 testers, most of whom have spent their entire careers on traditional SDLC "waterfall" projects. One of my, perhaps unenviable, tasks is to help transition these folks onto newly formed Agile teams. While I've had success, I wish I had this book sooner!

Crispin and Gregory have created a practical and very readable reference that shines a light on the roles of testers, and testing management -- areas that are often neglected in most of the work that I've found. Perhaps most importantly, they address the fear and apprehension that testers feel when faced with the prospect of joining an Agile team -- the same emotions I've seen (and felt) time and time again.

There's an appropriate mix of high level concepts and low level specifics. The book starts with discussions of principles and mindsets and moves on, in the later chapters to discuss such things as specific techniques of test automation. All along there are anecdotes from interviews with real agile teams and quoted articles from testing luminaries such as Brian Marick, Michael Bolten, et. al.

I've already begun to incorporate much of the material in these books into my own writings and presentations and it's certainly gratifying to see some of my own ideas mirrored. I now have solid references to back them up! I highly recommend this book for testers and testing managers who are planning to start on Agile projects, or who have years of experience on them. There's surely something in this book that will influence you.