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