What do you think?
Rate this book
A Mike Cohn Signature Book
Agile Testing: A Practical Guide for Testers and Agile Teams
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.
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.
533 pages, Paperback
First published January 1, 2008
251 people are currently reading
2190 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 74 reviews
September 29, 2013
Agile testing is a useful book, a decent introduction to somewhat neglected aspect of agile software development. It is also a book that could have benefitted from a sharper focus and more editing.
There are plenty of books on agile for project managers and programmers, testers are not so fortunate. Strange when you think about it. Testing is more profoundly affected than programming. Good programmers have been doing programming and unit and integration testing in parallel for ages, since long before agile became a buzzword. Testers in good organisations might have been involved from the start of the project even in staged projects, but their work was clearly divided into distinct planning and execution phases, and they had at best an arms-length relationship to the programmers. In agile they work closely with the programmers in cross-functional teams, concurrently designing and executing tests. They are no longer the gatekeepers to production, the quality police. Indeed, there is no strict delineation between the role of programmers and testers. Programmers test, testers pair with programmers in behaviour and test-driven development,
The agile and lean processes also have other profound implications for how testing is done. They prescribe frequent delivery of working software, in lean even on continuous delivery. That cannot be done without automation. Doing comprehensive regression testing manually will just take too long.
So, a book on agile testing is absolutely called for. This contains a lot of useful information. The most useful part of the book, is the division of testing into a two-by-two matrix. Along one axis you divide tests into those that support development and those that critique the product, along the other into those that are technology-facing and those that are business-facing.
In Quadrant 1, technology-facing tests that support development, you find unit, component and integration tests, the tests of test-driven development, the tests that usually are automated using frameworks such as JUnit. More often than not these are done by programmers, but on agile teams testers should not be shy to help.
In Quadrant 2, business-facing tests that support development, you find system-level functional tests, but also prototypes of various fidelities for user experience testing. The functional tests in this quadrant should be stated in the language of the users. The test serve as functional design artifacts for the system. These are the tests of behaviour- or example-driven development that can be automated using frameworks such as Fit, Fitnesse or Cucumber. Most of these tests should be done below the GUI layer, as the GUI usually is more fluid and GUI tests brittle. These tests should also be automated. Quite a departure for testers used to manually test against specification through the GUI.
In Quadrant 3, business-facing tests that critique the product, you find among other things exploratory testing, demonstrations, user-acceptance testing and usability testing. Exploratory testing is not the same as ad-hoc testing, it is a process of concurrent test design and execution, testing based on hypotheses ("smells") and learning. It can be highly effective in finding those insidious bugs, but without automation in the first two quadrants, there will rarely be enough time for this. Demonstrations, user-acceptance testing and usability testing are different in that they often involve people from outside the team.
In Quadrant 4, technology-facing tests that critique the product, you find tests of the -ilities, non-functional attributes such as performance and security. Interestingly the authors here include static analysis, which is not really a form of testing, but rather automated variants of that other family of quality control techniques, inspections. Manual inspections, in agile often done as pair-programming, is only lightly touched on in the book.
The authors stress that the four quadrants says nothing about when the different types of tests should be performed. If feasible and productive, they are all done in the sprints, but sometimes it can only be done later in the end game of the release.
The book also include parts on what testers should do in the various stages of an agile project such as release planning, sprint planning, during the sprint, after the sprint and at the end of the release; and how to handle the change from staged to incremental development - both organisational change and changes to the test of legacy software. These parts are unfortunately not as to-the-point as the part on the test quadrants. The authors seem to be repeating themselves and also rehashing a lot of non-test-specific material on agile. The book could have done with a sharper focus on testing and more editing, dare I say it -- yes, refactoring. As it is, it is a bit lengthy and somewhat trite. A final note, this is a book that will start showing its age as the tool landscape is changing rapidly, but this is not a major problem as the book is not handbook in using the various tools.
There are plenty of books on agile for project managers and programmers, testers are not so fortunate. Strange when you think about it. Testing is more profoundly affected than programming. Good programmers have been doing programming and unit and integration testing in parallel for ages, since long before agile became a buzzword. Testers in good organisations might have been involved from the start of the project even in staged projects, but their work was clearly divided into distinct planning and execution phases, and they had at best an arms-length relationship to the programmers. In agile they work closely with the programmers in cross-functional teams, concurrently designing and executing tests. They are no longer the gatekeepers to production, the quality police. Indeed, there is no strict delineation between the role of programmers and testers. Programmers test, testers pair with programmers in behaviour and test-driven development,
The agile and lean processes also have other profound implications for how testing is done. They prescribe frequent delivery of working software, in lean even on continuous delivery. That cannot be done without automation. Doing comprehensive regression testing manually will just take too long.
So, a book on agile testing is absolutely called for. This contains a lot of useful information. The most useful part of the book, is the division of testing into a two-by-two matrix. Along one axis you divide tests into those that support development and those that critique the product, along the other into those that are technology-facing and those that are business-facing.
In Quadrant 1, technology-facing tests that support development, you find unit, component and integration tests, the tests of test-driven development, the tests that usually are automated using frameworks such as JUnit. More often than not these are done by programmers, but on agile teams testers should not be shy to help.
In Quadrant 2, business-facing tests that support development, you find system-level functional tests, but also prototypes of various fidelities for user experience testing. The functional tests in this quadrant should be stated in the language of the users. The test serve as functional design artifacts for the system. These are the tests of behaviour- or example-driven development that can be automated using frameworks such as Fit, Fitnesse or Cucumber. Most of these tests should be done below the GUI layer, as the GUI usually is more fluid and GUI tests brittle. These tests should also be automated. Quite a departure for testers used to manually test against specification through the GUI.
In Quadrant 3, business-facing tests that critique the product, you find among other things exploratory testing, demonstrations, user-acceptance testing and usability testing. Exploratory testing is not the same as ad-hoc testing, it is a process of concurrent test design and execution, testing based on hypotheses ("smells") and learning. It can be highly effective in finding those insidious bugs, but without automation in the first two quadrants, there will rarely be enough time for this. Demonstrations, user-acceptance testing and usability testing are different in that they often involve people from outside the team.
In Quadrant 4, technology-facing tests that critique the product, you find tests of the -ilities, non-functional attributes such as performance and security. Interestingly the authors here include static analysis, which is not really a form of testing, but rather automated variants of that other family of quality control techniques, inspections. Manual inspections, in agile often done as pair-programming, is only lightly touched on in the book.
The authors stress that the four quadrants says nothing about when the different types of tests should be performed. If feasible and productive, they are all done in the sprints, but sometimes it can only be done later in the end game of the release.
The book also include parts on what testers should do in the various stages of an agile project such as release planning, sprint planning, during the sprint, after the sprint and at the end of the release; and how to handle the change from staged to incremental development - both organisational change and changes to the test of legacy software. These parts are unfortunately not as to-the-point as the part on the test quadrants. The authors seem to be repeating themselves and also rehashing a lot of non-test-specific material on agile. The book could have done with a sharper focus on testing and more editing, dare I say it -- yes, refactoring. As it is, it is a bit lengthy and somewhat trite. A final note, this is a book that will start showing its age as the tool landscape is changing rapidly, but this is not a major problem as the book is not handbook in using the various tools.
April 22, 2014
Far too many motherhood statements and far too little actionable advice.
November 26, 2013
I even don't know how to evaluate this book. One the hand I made about 20 notes, got some ideas and link to read from it, but on the other hand, in my mind, this book has too many useless explanations and stories that just blow you away from the main topic.
Several good ideas from this book:
- Shout-out box for the project
- Issue log might be your hidden feature log. Think about it.
- Pairing programmer and tester together for working on a feature
...
will not reveal the others :) just read this ~600 pages book.
Several good ideas from this book:
- Shout-out box for the project
- Issue log might be your hidden feature log. Think about it.
- Pairing programmer and tester together for working on a feature
...
will not reveal the others :) just read this ~600 pages book.
April 22, 2012
Good explanation on how it's like to be a tester in an Agile team. It also mention the potential challenges during Agile Transformation and the drag factors that can slower down a team from taking the full benefit of being Agile.
October 12, 2016
When my employer transitioned to use agile, we participated in agile training which consisted of an all-day lecture with provided notes, plus they joined in the “agile ceremonies” to lead the sessions and provide ideas.
There are some key ideas to agile which ensure quality throughout the process, and to provide small, incremental releases. Such ideas includes automation, test-driven development, flexible roles and more. This book does contain this information with examples of the author's (Lisa & Janet) experiences.
However, it's 533 pages long which is far too lengthy to get these points across. There's sections which really drag, with the constant reference to using FitNesse (75 mentions in total), which highlights the fact that there's plenty of text which could be cut. There's also lots of generic software development advice, rather than focussing on agile testing which the introduction emphasises. A big part of agile is finding out what works for your team and discussing the process in your retrospectives, rather than having a strict method that you must follow. The main point here, is that I found the training I received in my workplace (and trying to put it into practice) to be more helpful than this book.
I felt the example scenarios were very hit and miss. Some of them were great examples, whilst others seemed to simply exist to boost the author's ego. There's plenty that are structured like “company X had terrible practices until Lisa/Janet joined the company and suggest they do Y. After this, the company was highly productive”.
I think Agile books are inherently hard to write given it is very theoretical. Sure you can include the ideas, but can't provide specific instructions given that the methods aren't 'set in stone'. I do believe books like this need to be concise rather than verbose, otherwise it detracts from their utility. This is the reason why this book misses the mark.
There are some key ideas to agile which ensure quality throughout the process, and to provide small, incremental releases. Such ideas includes automation, test-driven development, flexible roles and more. This book does contain this information with examples of the author's (Lisa & Janet) experiences.
However, it's 533 pages long which is far too lengthy to get these points across. There's sections which really drag, with the constant reference to using FitNesse (75 mentions in total), which highlights the fact that there's plenty of text which could be cut. There's also lots of generic software development advice, rather than focussing on agile testing which the introduction emphasises. A big part of agile is finding out what works for your team and discussing the process in your retrospectives, rather than having a strict method that you must follow. The main point here, is that I found the training I received in my workplace (and trying to put it into practice) to be more helpful than this book.
I felt the example scenarios were very hit and miss. Some of them were great examples, whilst others seemed to simply exist to boost the author's ego. There's plenty that are structured like “company X had terrible practices until Lisa/Janet joined the company and suggest they do Y. After this, the company was highly productive”.
I think Agile books are inherently hard to write given it is very theoretical. Sure you can include the ideas, but can't provide specific instructions given that the methods aren't 'set in stone'. I do believe books like this need to be concise rather than verbose, otherwise it detracts from their utility. This is the reason why this book misses the mark.
May 16, 2016
Should have been called
"Agile development from a tester's perspective"
Really didn't like this book. For the thickness, I was expecting a book about how to test in an Agile project, instead it focused more on how to work in general in an agile project.
Reviews on Amazon said this book was a bit outdated and the new version "More Agile Testing" mentions that the views they had are outdated in this book, but I figure I'd get some nuggets of knowledge.
Only part I can take with me for the future is some qualities to look for when hiring a QA team lead/manager.
Overall very disappointed. I wouldn't recommend this to anyone.
Even if they were new to agile. I'd have them read "Scrum: The art of doing twice the work in half the time" instead.
"Agile development from a tester's perspective"
Really didn't like this book. For the thickness, I was expecting a book about how to test in an Agile project, instead it focused more on how to work in general in an agile project.
Reviews on Amazon said this book was a bit outdated and the new version "More Agile Testing" mentions that the views they had are outdated in this book, but I figure I'd get some nuggets of knowledge.
Only part I can take with me for the future is some qualities to look for when hiring a QA team lead/manager.
Overall very disappointed. I wouldn't recommend this to anyone.
Even if they were new to agile. I'd have them read "Scrum: The art of doing twice the work in half the time" instead.
February 4, 2014
This book would benefit from reediting in an attempt to make it more to the point with less text.
April 16, 2023
It's hard to judge a book when so much of the content is new to me. I must admit that there were parts I skimmed through because my current experience is still too small to fully understand all the details.
That being said, I believe I'll come back to this book in times of need.
That being said, I believe I'll come back to this book in times of need.
March 6, 2019
It is nasty and informative
This entire review has been hidden because of spoilers.
November 9, 2018
The target audience for this book seems to be: software testers with a background that's not in an agile environment. Since I am working in an agile environment, but only partially as a tester, this book didn't fully resonate with me.
Also, I was kinda annoyed that the tester was portrayed as the center point in about everything that the team does. While I get that testing isn't just something that you do after development, I think this aspect was over-stressed and belittled the roles of other people on the team.
Also, I was kinda annoyed that the tester was portrayed as the center point in about everything that the team does. While I get that testing isn't just something that you do after development, I think this aspect was over-stressed and belittled the roles of other people on the team.
October 14, 2016
The book is really valuable and contains much useful information. But it is overloaded with information and also there is lot of text which wasn't necessary and just makes the book bigger and hard to read. That's why it's hard to keep focus and do not lost in all this information. May be it would be better to create several separated books if authors wanted to put so much or make the book more focused on the most important stuff.
December 18, 2017
This book is good, but a little bit old. Back then (2008) the authors presented a radical change of software testing and for me it would have been a 5/5. The book still contains some valuable insights today (2017). This book definitely needs a new and updated edition.
October 17, 2023
The book is good for anyone who knows about the Agile approach generally and testing part of it specifically. It gives a brief of Agile testing and teams who are involved with developing software products. Starting from ten principles for Agile testers that were inspired by the Agile Manifesto, culture challenges (especially organizational challenges), types of testing such as UAT, Regression Testing, Exploratory Testing, Unit Test, and some practices like Test-Driven Development (came from Extreme Programming methodology). Also enabling automation on testing and its strategy, and what kind of testing to automate.
The interesting parts of the book for me were principles, automation, and key success factors. The reason is that practicing agile and testing begins with creating a continuous improvement culture first, building trust and strong communication between the whole team members. Then useful practices such as agile testing can be used to improve and build the software product. Last but not least is the consideration of customer centricity while testing and building the software product that involves the customer during the iteration and improvement based on received feedback and so on to meet the customer needs.
The interesting parts of the book for me were principles, automation, and key success factors. The reason is that practicing agile and testing begins with creating a continuous improvement culture first, building trust and strong communication between the whole team members. Then useful practices such as agile testing can be used to improve and build the software product. Last but not least is the consideration of customer centricity while testing and building the software product that involves the customer during the iteration and improvement based on received feedback and so on to meet the customer needs.
May 20, 2025
For a book covering a topic that stresses adaptability and communication, the content is stiff and unweildy. There is a lot of helpful points in here that serve as an introduction to agile methodology in a testing context, but I think the topics the book covers are so broad and unfocused that it struggles to organize itself into any clear identity. I think you could easily trim half the pages in this book off and have it be just as potent. The "tester" identity being taught about seems to be a combination of a QA manager and their suboordinates, but the constant jumping back and forth between the two personas creates a grey wiplash that makes it incredibly easy to tune out large segments of the book. The information is good, it is just a massive pain to read through.
December 21, 2017
Excellent read for a first time tester or someone who migrated from support into product development. Will be recommending a selection of chapters as must read material for new team members.
Chapters 18 & 20 provide a great overview of the entire development process for a new tester.
Chapters 1-5 address very real culture issues around testing and how to transition into a healthier place.
Chapters 14-18 are the real meat of this book with lots of real examples of projects and interactions between parties. Yes, it’s a bit outdated, but I wish I would have had this book when I started my testing career.
Chapters 18 & 20 provide a great overview of the entire development process for a new tester.
Chapters 1-5 address very real culture issues around testing and how to transition into a healthier place.
Chapters 14-18 are the real meat of this book with lots of real examples of projects and interactions between parties. Yes, it’s a bit outdated, but I wish I would have had this book when I started my testing career.
December 10, 2019
Good book to learn more about testing in the world of agile. It's heavily inspired by XP practices, which makes it a bit dated given that XP is not as huge as it once was. Though that doesn't make many of the suggestions any less relevant.
The many examples that the book provide are great illustrations, but sometimes there are so many you get tired of them.
That all said, I recommend this book for those wanting to do better at testing with agile. Also good for non-testers who want to learn more about testing:
The many examples that the book provide are great illustrations, but sometimes there are so many you get tired of them.
That all said, I recommend this book for those wanting to do better at testing with agile. Also good for non-testers who want to learn more about testing:
September 13, 2021
I probably bought this book soon after it was published, and it sat until I was appointed "QA Lead" for a team implementing on the Salesforce platform.
For me it was a very helpful introduction to the modern testing landscape, and some principles to decide where to focus and what to automate, or not.
The book contains a lot of material for professional testers and other QA people whose teams or shops are "going Agile" and who are trying to understand what that means. I'm not at all qualified to evaluate that.
For me it was a very helpful introduction to the modern testing landscape, and some principles to decide where to focus and what to automate, or not.
The book contains a lot of material for professional testers and other QA people whose teams or shops are "going Agile" and who are trying to understand what that means. I'm not at all qualified to evaluate that.
April 2, 2018
The most important take away for me are the 4 Quadrant overview and the tips and tricks that come from practice. I expected something way more technical but it reads quite easily and is suitable for non tech readers. I felt that some concepts have been repeated ovher and over again which was pretty annoying to me. I would have preferred a more focused and to the point style. Still a book to recommend.
August 4, 2022
Excellent book that has helped me navigate what it means to be a testers during the time when many companies were trying to figure out how to navigate from waterfall style development to agile. When I read this I was working at a company that was nominally agile but still had testing teams separate from the development teams. This book as really helpful for me in seeking to transition to a more agile approach with testing truly adding value
May 28, 2017
Muy bueno y muy descriptivo de todo pormenor del testing en Agile. Tan extenso que a ratos estuve tentado a darle solo 4 estrellas pudiendo haber sido un poco mas resumido.
Aun asi, recomendable para cualquier tester que este por entrar en el mundo de los proyectos Agile, es un mundo de cambios desde el testing tradicional.
Aun asi, recomendable para cualquier tester que este por entrar en el mundo de los proyectos Agile, es un mundo de cambios desde el testing tradicional.
December 21, 2019
I admit: I didn't read it through completely. The first few chapters introduce a framework (quadrants) and explain it high level. That in itself is absolutely worth the 5 stars. The rest of the book then goes in detail further, which is for me (personally) not really need. Still: recommended for anyone when the title rings a bell
March 2, 2025
Dated in today's world but still offers decent advice - it felt aimed at junior to mid level individuals. The book is focused from a testers perspective (as expected) but talks across software roles. The latter half offers practical examples of iterations in a team, but would benefit from offering structured lists of processes or practices. Overall worth a read if you can get it for cheap
January 13, 2019
This was a great book on how testing can be accomplished in an Agile team. This book taught me that the testers can be involved at the planning, through programming, and into a release. It also taught me the importance of test automation to meet deadlines. It was easy to read and very practical.
July 13, 2019
Come with lots of real-experience examples. Answer the question when need to transit to Agile world such as documentation and some activities. Coverage for full SDLC. I love to read it even it contains too much text and not much pictures. Best even newbie or revisit knowledge you already known.
October 12, 2023
I was reading this for work (QA Engineer) and I loved what I was reading. However I've switched jobs to Software Engineer and need to make room on my reading plate for other more relatable books. I would DEFINITELY recommend this book to anyone in QA though.
August 16, 2018
It was better than I expected. I thought it will be outdated and obvious, but it still has some useful tips and good description of agile approach at work
February 20, 2019
This book was a slog and not fun to read but it does have lots of great information.
February 25, 2019
Very good for those who starts testing in agile team.
October 4, 2019
Hands down, the best book I've read so far for modern software testing.
February 2, 2020
This book is not about testing.
Displaying 1 - 30 of 74 reviews