Agile Testing: A Practical Guide for Testers and Agile Teams

Paperback (Print)
Rent
Rent from BN.com
$14.93
(Save 75%)
Est. Return Date: 12/01/2014
Used and New from Other Sellers
Used and New from Other Sellers
from $35.82
Usually ships in 1-2 business days
(Save 40%)
Other sellers (Paperback)
  • All (17) from $35.82   
  • New (11) from $38.74   
  • Used (6) from $37.20   

Overview

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.
Read More Show Less

Editorial Reviews

From the Publisher
“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

Read More Show Less

Product Details

  • ISBN-13: 9780321534460
  • Publisher: Addison-Wesley
  • Publication date: 1/9/2009
  • Series: Addison-Wesley Signature Series
  • Edition description: New Edition
  • Pages: 576
  • Sales rank: 169,663
  • Product dimensions: 6.80 (w) x 9.10 (h) x 1.20 (d)

Meet 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.

Read More Show Less

Read an Excerpt

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 betterintegrate 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 testing are addressed.
  • My concerns and fears about having to write code (never done it) are addressed.
  • As a tester I understand my new value to the team.
  • As a tester new to Agile, I can easily read about things that are most important to my new role.
  • As a tester new to Agile, I can easily ignore things that are less important to my new role.
  • As a tester new to Agile, I can easily get further detail about agile testing that is important to MY context.

Were I to suggest a solution to this problem, I think of Scrum versus XP. With Scrum you get a simple view that enables people to quickly adopt Agile. However, Scrum is the tip of the iceberg for successful agile teams. For testers who are new, I would love to see agile testing ideas expressed in layers of detail. What do I need to know today, what should I know tomorrow, and what context-sensitive things should I consider for continuous improvement?

We’ve tried to provide these layers of detail in this book. We’ll approach agile testing from a few different perspectives: transitioning into agile development, using an agile testing matrix to guide testing efforts, and explaining all the different testing activities that take place throughout the agile development cycle.

How to Use This Book

If you aren’t sure where to start in this book, or you just want a quick overview, we suggest you read the last chapter, Chapter 22, “Key Success Factors,” and follow wherever it leads you. Part I: Introduction

If you want quick answers to questions such as “Is agile testing different than testing on waterfall projects?” or “What’s the difference between a tester on a traditional team and an agile tester?,” start with Part I, which includes the following chapters:

  • Chapter 1: What Is Agile Testing, Anyway?
  • Chapter 2: Ten Principles for Agile Testers

These chapters are the “tip of the iceberg” that Robin requested in his user story. They include an overview of how agile differs from a traditional phased approach and explore the “whole team” approach to quality and testing.

In this part of the book we define the “agile testing mind-set” and what makes testers successful on agile teams. We explain how testers apply agile values and principles to contribute their particular expertise. Part II: Organizational Challenges

If you’re a tester or manager on a traditional QA team, or you’re coaching a team that’s moving to agile, Part II will help you with the organizational challenges faced by teams in transition. The “whole team” attitude represents a lot of cultural changes to team members, but it helps overcome the fear testers have when they wonder how much control they’ll have or whether they’ll be expected to write code.

Some of the questions answered in Part II are:

  • How can we engage the QA team?
  • What about management’s expectations?
  • How should we structure our agile team, and where do the testers fit?
  • What do we look for when hiring an agile tester?
  • How do we cope with a team distributed across the globe?

Part II also introduces some topics we don’t always enjoy talking about. We explore ideas about how to transition processes and models, such as audits or SOX compliance, that are common in traditional environments.

Metrics and how they’re applied can be a controversial issue, but there are positive ways to use them to benefit the team. Defect tracking easily becomes a point of contention for teams, with questions such as “Do we use a defect-tracking system?” or “When do we log bugs?”

Two common questions about agile testing from people with traditional test team experience are “What about test plans?” and “Is it true there’s no documentation on agile projects?” Part II clears up these mysteries.

The chapters in Part II are as follows:

  • Chapter 3: Cultural Challenges
  • Chapter 4: Team Logistics
  • Chapter 5: Transitioning Typical Processes
Part III: The Agile Testing Quadrants

Do you want more details on what types of testing are done on agile projects? Are you wondering who does what testing? How do you know whether you’ve done all the testing that’s needed? How do you decide what practices, techniques, and tools fit your particular situation? If these are your concerns, check out Part III.

We use Brian Marick’s Agile Testing Quadrants to explain the purpose of testing. The quadrants help you define all the different areas your testing should address, from unit level tests to reliability and other “ilities,” and everything in between. This is where we get down into the nitty-gritty of how to deliver a high-quality product. We explain techniques that can help you to communicate well with your customers and better understand their requirements. This part of the book shows how tests drive development at multiple levels. It also provides tools for your toolkit that can help you to effectively define, design, and execute tests that support the team and critique the product. The chapters include the following:

  • Chapter 6: The Purpose of Testing
  • Chapter 7: Technology-Facing Tests that Support the Team
  • Chapter 8: Business-Facing Tests that Support the Team
  • Chapter 9: Toolkit for Business-Facing Tests that Support the Team
  • Chapter 10: Business-Facing Tests that Critique the Product
  • Chapter 11: Critiquing the Product Using Technology-Facing Tests
  • Chapter 12: Summary of Testing Quadrants
Part IV: Automation

Test automation is a central focus of successful agile teams, and it’s a scary topic for lots of people (we know, because it’s had us running scared before!). How do you squeeze test automation into short iterations and still get all the stories completed?

Part IV gets into the details of when and why to automate, how to overcome barriers to test automation, and how to develop and implement a test automation strategy that works for your team. Because test automation tools change and evolve so rapidly, our aim is not to explain how to use specific tools, but to help you select and use the right tools for your situation. Our agile test automation tips will help you with difficult challenges such as testing legacy code.

The chapters are as follows:

  • Chapter 13: Why We Want to Automate Tests and What Holds Us Back
  • Chapter 14: An Agile Test Automation Strategy
Part V: An Iteration in the Life of a Tester

If you just want to get a feel for what testers do throughout the agile development cycle, or you need help putting together all the information in this book, go to Part V. Here we chronicle an iteration, and more, in the life of an agile tester. Testers contribute enormous value throughout the agile software development cycles. In Part V, we explain the activities that testers do on a daily basis. We start with planning releases and iterations to get each iteration off to a good start, and move through the iteration—collaborating with the customer and development teams, testing, and writing code. We end the iteration by delivering new features and finding ways for the team to improve the process.

The chapters break down this way:

  • Chapter 15: Tester Activities in Release or Theme Planning
  • Chapter 16: Hit the Ground Running
  • Chapter 17: Iteration Kickoff
  • Chapter 18: Coding and Testing
  • Chapter 19: Wrap Up the Iteration
  • Chapter 20: Successful Delivery
Part VI: Summary

In Chapter 21, “Key Success Factors,” we present seven key factors agile teams can use for successful testing. If you’re having trouble deciding where to start with agile testing, or how to work on improving what you’re doing now, these success factors will give you some direction.Other Elements

We’ve also included a glossary we hope you will find useful, as well as references to books, articles, websites, and blogs in the bibliography.Just Start Doing It—Today!

Agile development is all about doing your best work. Every team has unique challenges. We’ve tried to present all the information that we think may help agile testers, their teams, managers, and customers. Apply the techniques that you think are appropriate for your situation. Experiment constantly, evaluate the results, and come back to this book to see what might help you improve. Our goal is to help testers and agile teams enjoy delivering the best and most valuable product they can.

When we asked Dierk König, founder and project manager of Canoo WebTest, what he thought was the number one success factor for agile testing, he answered: “Start doing it—today!” You can take a baby step to improve your team’s testing right now. Go get started!

© Copyright Pearson Education. All rights reserved.

Read More Show Less

Table of Contents

Foreword by Mike Cohn xxiii
Foreword by Brian Marick xxv
Preface xxvii
Acknowledgments xxxvii
About the Authors xli


Part I: Introduction 1
Chapter 1: What Is Agile Testing, Anyway? 3

Agile Values 3
What Do We Mean by “Agile Testing”? 4
A Little Context for Roles and Activities on an Agile Team 7
How Is Agile Testing Different? 9
Whole-Team Approach 15
Summary 17

Chapter 2: Ten Principles for Agile Testers 19
What’s an Agile Tester? 19
The Agile Testing Mind-Set 20
Applying Agile Principles and Values 21
Adding Value 31
Summary 33

Part II: Organizational Challenges 35
Chapter 3: Cultural Challenges 37

Organizational Culture 37
Barriers to Successful Agile Adoption by Test/QA Teams 44
Introducing Change 49
Management Expectations 52
Change Doesn’t Come Easy 56
Summary 58

Chapter 4: Team Logistics 59
Team Structure 59
Physical Logistics 65
Resources 66
Building a Team 69
Summary 71

Chapter 5: Transitioning Typical Processes 73
Seeking Lightweight Processes 73
Metrics 74
Defect Tracking 79
Test Planning 86
Existing Processes and Models 88
Summary 93

Part III: The Agile Testing Quadrants 95
Chapter 6: The Purpose of Testing 97

The Agile Testing Quadrants 97
Knowing When a Story Is Done 104
Managing Technical Debt 106
Testing in Context 106
Summary 108

Chapter 7: Technology-Facing Tests that Support the Team 109
An Agile Testing Foundation 109
Why Write and Execute These Tests? 112
Where Do Technology-Facing Tests Stop? 119
What If the Team Doesn’t Do These Tests? 121
Toolkit 123
Summary 127

Chapter 8: Business-Facing Tests that Support the Team 129
Driving Development with Business-Facing Tests 129
The Requirements Quandary 132
Thin Slices, Small Chunks 144
How Do We Know We’re Done? 146
Tests Mitigate Risk 147
Testability and Automation 149
Summary 150

Chapter 9: Toolkit for Business-Facing Tests that Support the Team 153
Business-Facing Test Tool Strategy 153
Tools to Elicit Examples and Requirements 155
Tools for Automating Tests Based on Examples 164
Strategies for Writing Tests 177
Testability 183
Test Management 186
Summary 186

Chapter 10: Business-Facing Tests that Critique the Product 189
Introduction to Quadrant 3 190
Demonstrations 191
Scenario Testing 192
Exploratory Testing 195
Usability Testing 202
Behind the GUI 204
Testing Documents and Documentation 207
Tools to Assist with Exploratory Testing 210
Summary 214

Chapter 11: Critiquing the Product Using Technology-Facing Tests 217
Introduction to Quadrant 4 217
Who Does It? 220
When Do You Do It? 222
“ility” Testing 223
Performance, Load, Stress, and Scalability Testing 233
Summary 238

Chapter 12: Summary of Testing Quadrants 241
Review of the Testing Quadrants 241
A System Test Example 242
Tests Driving Development 244
Automation 245
Critiquing the Product with Business-Facing Tests 248
Documentation 251
Using the Agile Testing Quadrants 252
Summary 253

Part IV: Automation 255
Chapter 13: Why We Want to Automate Tests and What Holds Us Back 257

Why Automate? 258
Barriers to Automation—Things that Get in the Way 264
Can We Overcome These Barriers? 270
Summary 271

Chapter 14: An Agile Test Automation Strategy 273
An Agile Approach to Test Automation 274
What Can We Automate? 279
What Shouldn’t We Automate? 285
What Might Be Hard to Automate? 287
Developing an Automation Strategy—Where Do We Start? 288
Applying Agile Principles to Test Automation 298
Supplying Data for Tests 304
Evaluating Automation Tools 311
Implementing Automation 316
Managing Automated Tests 319
Go Get Started 324
Summary 324

Part V: An Iteration in the Life of a Tester 327
Chapter 15: Tester Activities in Release or Theme Planning 329

The Purpose of Release Planning 330
Sizing 332
Prioritizing 338
What’s in Scope? 340
Test Planning 345
Test Plan Alternatives 350
Preparing for Visibility 354
Summary 366

Chapter 16: Hit the Ground Running 369
Be Proactive 369
Advance Clarity 373
Examples 378
Test Strategies 380
Prioritize Defects 381
Resources 381
Summary 382

Chapter 17: Iteration Kickoff 383
Iteration Planning 383
Testable Stories 393
Collaborate with Customers 396
High-Level Tests and Examples 397
Summary 403

Chapter 18: Coding and Testing 405
Driving Development 406
Tests that Critique the Product 412
Collaborate with Programmers 413
Talk to Customers 414
Completing Testing Tasks 415
Dealing with Bugs 416
It’s All about Choices 419
Facilitate Communication 429
Regression Tests 432
Resources 434
Iteration Metrics 435
Summary 440

Chapter 19: Wrap Up the Iteration 443
Iteration Demo 443
Retrospectives 444
Celebrate Successes 449
Summary 451

Chapter 20: Successful Delivery 453
What Makes a Product? 453
Planning Enough Time for Testing 455
The End Game 456
Customer Testing 464
Post-Development Testing Cycles 467
Deliverables 468
Releasing the Product 470
Customer Expectations 475
Summary 476

Part VI: Summary 479
Chapter 21: Key Success Factors 481

Success Factor 1: Use the Whole-Team Approach 482
Success Factor 2: Adopt an Agile Testing Mind-Set 482
Success Factor 3: Automate Regression Testing 484
Success Factor 4: Provide and Obtain Feedback 484
Success Factor 5: Build a Foundation of Core Practices 486
Success Factor 6: Collaborate with Customers 489
Success Factor 7: Look at the Big Picture 490
Summary 491

Glossary 493
Bibliography 501
Index 509

Read More Show Less

Preface

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 testing are addressed.
  • My concerns and fears about having to write code (never done it) are addressed.
  • As a tester I understand my new value to the team.
  • As a tester new to Agile, I can easily read about things that are most important to my new role.
  • As a tester new to Agile, I can easily ignore things that are less important to my new role.
  • As a tester new to Agile, I can easily get further detail about agile testing that is important to MY context.

Were I to suggest a solution to this problem, I think of Scrum versus XP. With Scrum you get a simple view that enables people to quickly adopt Agile. However, Scrum is the tip of the iceberg for successful agile teams. For testers who are new, I would love to see agile testing ideas expressed in layers of detail. What do I need to know today, what should I know tomorrow, and what context-sensitive things should I consider for continuous improvement?

We’ve tried to provide these layers of detail in this book. We’ll approach agile testing from a few different perspectives: transitioning into agile development, using an agile testing matrix to guide testing efforts, and explaining all the different testing activities that take place throughout the agile development cycle.

How to Use This Book

If you aren’t sure where to start in this book, or you just want a quick overview, we suggest you read the last chapter, Chapter 22, “Key Success Factors,” and follow wherever it leads you.

Part I: Introduction

If you want quick answers to questions such as “Is agile testing different than testing on waterfall projects?” or “What’s the difference between a tester on a traditional team and an agile tester?,” start with Part I, which includes the following chapters:

  • Chapter 1: What Is Agile Testing, Anyway?
  • Chapter 2: Ten Principles for Agile Testers

These chapters are the “tip of the iceberg” that Robin requested in his user story. They include an overview of how agile differs from a traditional phased approach and explore the “whole team” approach to quality and testing.

In this part of the book we define the “agile testing mind-set” and what makes testers successful on agile teams. We explain how testers apply agile values and principles to contribute their particular expertise.

Part II: Organizational Challenges

If you’re a tester or manager on a traditional QA team, or you’re coaching a team that’s moving to agile, Part II will help you with the organizational challenges faced by teams in transition. The “whole team” attitude represents a lot of cultural changes to team members, but it helps overcome the fear testers have when they wonder how much control they’ll have or whether they’ll be expected to write code.

Some of the questions answered in Part II are:

  • How can we engage the QA team?
  • What about management’s expectations?
  • How should we structure our agile team, and where do the testers fit?
  • What do we look for when hiring an agile tester?
  • How do we cope with a team distributed across the globe?

Part II also introduces some topics we don’t always enjoy talking about. We explore ideas about how to transition processes and models, such as audits or SOX compliance, that are common in traditional environments.

Metrics and how they’re applied can be a controversial issue, but there are positive ways to use them to benefit the team. Defect tracking easily becomes a point of contention for teams, with questions such as “Do we use a defect-tracking system?” or “When do we log bugs?”

Two common questions about agile testing from people with traditional test team experience are “What about test plans?” and “Is it true there’s no documentation on agile projects?” Part II clears up these mysteries.

The chapters in Part II are as follows:

  • Chapter 3: Cultural Challenges
  • Chapter 4: Team Logistics
  • Chapter 5: Transitioning Typical Processes

Part III: The Agile Testing Quadrants

Do you want more details on what types of testing are done on agile projects? Are you wondering who does what testing? How do you know whether you’ve done all the testing that’s needed? How do you decide what practices, techniques, and tools fit your particular situation? If these are your concerns, check out Part III.

We use Brian Marick’s Agile Testing Quadrants to explain the purpose of testing. The quadrants help you define all the different areas your testing should address, from unit level tests to reliability and other “ilities,” and everything in between. This is where we get down into the nitty-gritty of how to deliver a high-quality product. We explain techniques that can help you to communicate well with your customers and better understand their requirements. This part of the book shows how tests drive development at multiple levels. It also provides tools for your toolkit that can help you to effectively define, design, and execute tests that support the team and critique the product. The chapters include the following:

  • Chapter 6: The Purpose of Testing
  • Chapter 7: Technology-Facing Tests that Support the Team
  • Chapter 8: Business-Facing Tests that Support the Team
  • Chapter 9: Toolkit for Business-Facing Tests that Support the Team
  • Chapter 10: Business-Facing Tests that Critique the Product
  • Chapter 11: Critiquing the Product Using Technology-Facing Tests
  • Chapter 12: Summary of Testing Quadrants

Part IV: Automation

Test automation is a central focus of successful agile teams, and it’s a scary topic for lots of people (we know, because it’s had us running scared before!). How do you squeeze test automation into short iterations and still get all the stories completed?

Part IV gets into the details of when and why to automate, how to overcome barriers to test automation, and how to develop and implement a test automation strategy that works for your team. Because test automation tools change and evolve so rapidly, our aim is not to explain how to use specific tools, but to help you select and use the right tools for your situation. Our agile test automation tips will help you with difficult challenges such as testing legacy code.

The chapters are as follows:

  • Chapter 13: Why We Want to Automate Tests and What Holds Us Back
  • Chapter 14: An Agile Test Automation Strategy

Part V: An Iteration in the Life of a Tester

If you just want to get a feel for what testers do throughout the agile development cycle, or you need help putting together all the information in this book, go to Part V. Here we chronicle an iteration, and more, in the life of an agile tester. Testers contribute enormous value throughout the agile software development cycles. In Part V, we explain the activities that testers do on a daily basis. We start with planning releases and iterations to get each iteration off to a good start, and move through the iteration—collaborating with the customer and development teams, testing, and writing code. We end the iteration by delivering new features and finding ways for the team to improve the process.

The chapters break down this way:

  • Chapter 15: Tester Activities in Release or Theme Planning
  • Chapter 16: Hit the Ground Running
  • Chapter 17: Iteration Kickoff
  • Chapter 18: Coding and Testing
  • Chapter 19: Wrap Up the Iteration
  • Chapter 20: Successful Delivery

Part VI: Summary

In Chapter 21, “Key Success Factors,” we present seven key factors agile teams can use for successful testing. If you’re having trouble deciding where to start with agile testing, or how to work on improving what you’re doing now, these success factors will give you some direction.

Other Elements

We’ve also included a glossary we hope you will find useful, as well as references to books, articles, websites, and blogs in the bibliography.

Just Start Doing It—Today!

Agile development is all about doing your best work. Every team has unique challenges. We’ve tried to present all the information that we think may help agile testers, their teams, managers, and customers. Apply the techniques that you think are appropriate for your situation. Experiment constantly, evaluate the results, and come back to this book to see what might help you improve. Our goal is to help testers and agile teams enjoy delivering the best and most valuable product they can.

When we asked Dierk König, founder and project manager of Canoo WebTest, what he thought was the number one success factor for agile testing, he answered: “Start doing it—today!” You can take a baby step to improve your team’s testing right now. Go get started!

© Copyright Pearson Education. All rights reserved.

Read More Show Less

Customer Reviews

Average Rating 4
( 5 )
Rating Distribution

5 Star

(3)

4 Star

(0)

3 Star

(2)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 – 8 of 5 Customer Reviews
  • Posted March 22, 2009

    The definitive guide and reference for how to test on an agile project

    This is an excellent book that deserves to be read by every tester on an agile project--and since agile projects largely try to do away with specific roles, everyone tests, making this a great book for almost anyone on an agile team. The book starts by laying groundwork by defining what agile testing is and describing ten principles for doing it. Part 2 touches on the organizational changes that will be felt by the testing or QA group as the company transitions to agile.

    Part 3 is probably the centerpiece of the book. It is structured around four testing quadrants initially conceived of by Agile Manifesto co-author Brian Marick. These quadrants allow Crispin and Gregory to cover a broad range of topics including exploratory, UI, API, usability, performance, stress, and reliability testing. The book definitely goes beyond the basics and the authors don't shy away from challenging topics.

    Part 4 covers automation, a topic that should be on the minds of any agile team. One of my favorite sections in this part is the discussion of barriers to automation. The advice here should help many teams overcome some of the resistance created by these barriers. Part 5 is an interesting section that brings the ideas of the book together by walking chronologically through the typical events of an iteration and focusing on the activities of testers at those times. Part 6 concludes with a short list of critical success factors.

    I like that this book is both universal and personal. It is chock-full of universal, practical advice but the author's make liberal use of sidebars in which they tell their own personal stories. This combination of telling us how something should be done and then adding detail in the form of how they did it works very well. By the end of the book you have learned a great deal about testing and these two world-class testers.

    Very highly recommended.

    2 out of 2 people found this review helpful.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted December 9, 2011

    No text was provided for this review.

  • Anonymous

    Posted April 29, 2011

    No text was provided for this review.

  • Anonymous

    Posted January 11, 2010

    No text was provided for this review.

  • Anonymous

    Posted January 1, 2011

    No text was provided for this review.

  • Anonymous

    Posted January 22, 2010

    No text was provided for this review.

  • Anonymous

    Posted January 19, 2010

    No text was provided for this review.

  • Anonymous

    Posted February 2, 2011

    No text was provided for this review.

Sort by: Showing 1 – 8 of 5 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)