- Used Books
- Staff Picks
- Gifts & Gift Cards
- Sell Books
- Stores & Events
- Let's Talk Books
Special Offers see all
More at Powell's
Recently Viewed clear list
New Trade Paper
Ships in 1 to 3 days
available for shipping or prepaid pickup only
More copies of this ISBN
Other titles in the Addison-Wesley Signature series:
Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley Signature Series)by Lisa Crispin
We were early adopters of Extreme Programming (XP), testing on XP teams that werent at all sure where testers or their brand of testing fit in. At the time, there wasnt much in the agile (which wasnt 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, weve learned a whole lot more about agile testing.
Individually and together, weve 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 others 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.
Weve 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. Weve 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, weve focused on the role of the tester, a role that may be adopted by a variety of professionals.
Agile testing practices arent 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 isnt the only way to successfully deliver software. However, all of the successful teams weve 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 arent 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 couldnt “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, weve included the mind map as part of the opening of each chapter. We hope theyll help you get an overview of all the information included in the chapter, and inspire you to try using mind maps yourself.
This book will help you if youve ever asked any of the following excellent questions, which weve heard many times:
If you have similar questions and youre looking for practical advice about how testers contribute to agile teams and how agile teams can do an effective job of testing, youve 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 youre practicing Scrum, Extreme Programming, Crystal, DSDM, or your own variation of agile development, youll find information here to help with your testing efforts.
How to Use This Book
If you arent 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 “Whats the difference between a tester on a traditional team and an agile tester?,” start with Part I, which includes the following chapters:
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 youre a tester or manager on a traditional QA team, or youre coaching a team thats 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 theyll have or whether theyll be expected to write code.
Some of the questions answered in Part II are:
Part II also introduces some topics we dont 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 theyre 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 theres no documentation on agile projects?” Part II clears up these mysteries.
The chapters in Part II are as follows:
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 youve done all the testing thats 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 Maricks 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:
Part IV: Automation
Test automation is a central focus of successful agile teams, and its a scary topic for lots of people (we know, because its 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:
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:
Part VI: Summary
In Chapter 21, “Key Success Factors,” we present seven key factors agile teams can use for successful testing. If youre having trouble deciding where to start with agile testing, or how to work on improving what youre doing now, these success factors will give you some direction.
Weve 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. Weve 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 teams testing right now. Go get started!
© Copyright Pearson Education. All rights reserved.
What Our Readers Are Saying
Average customer rating based on 1 comment:
Computers and Internet » Computers Reference » General