In honor of running into Janet Gregory at EuroSTAR and listening to her talk about “Testing Traps to Avoid in Agile Teams“, I told her I felt it only proper to break my Tsundoku and commit to reading “More Agile Testing” on my flight from Ireland to Toronto and during my layover for my flight back to SFO and review it before I got home. Did I succeed? I did, and I am glad I had the dedicated time to do exactly that. This book is so rich with information that you will need to spend some quality time with it.
First, let’s set some context. This is the sequel to the “Agile Testing” book that Lisa Crispin and Janet Gregory wrote back in 2008, and that I did a review of in the early days of the TESTHEAD blog back in 2010. In that review, I said that I didn’t have the time in an Agile team to give the book justice, so I reviewed it on how I thought that Agile seemed to me and the advice given. This time, with More Agile Testing, I have four and a half years of experience with Agile teams, and I can categorically say yes, this book addresses many of the challenges Agilists go through, especially Agile Testers.
Agile has grown and matured over the past several years. Some may say it has a clearer picture of itself, others may say its become fragmented and just another marketing gimmick. Some may complain that Agile programming is a thing, but Agile Testing? All of this points to the fact that there are questions, dilemmas and issues in the world of Agile, and nowhere is that more clear (or more muddled) than for the Agile Tester. Are we an appendage? Are we an integrated member of the team? Are we an anachronism? What about DevOps? Continuous Delivery? Testing in Production? Lisa and Janet take on all of these issues, and more.
More Agile Testing is not a “how” book. It’s not filled with recipes of how to be an Agile tester… at least not on the surface. Don’t get me wrong, there is a ton of actionable stuff in this book, and anyone working with Agile teams will learn a lot and develop some new appreciation and approaches. What I mean about it not being a “how” book is that it doesn’t tell you specifically what to do. Instead, it is a “what” book, and there’s a whole lot of “what” in its pages. Like its predecessor, More Agile Testing does not need to be read cover to cover (though that’s a perfectly good way to read it, and the first time through, i’d highly recommend doing just that). Instead, each section can stand on its own, and each chapter is formatted to address specific challenges Agile teams face. 
The book is broken up into eight sections. The first is an overview of where Agile has evolved, and the new aspects that are in play that were not so prevalent in 2008 when Agile Testing came out. In addition, it takes a look at the ways that organizations have changed, and the new landscape of software development for applications that span the gamut from desktop to web to mobile to embedded to the Internet of Things.
Section Two is all about Learning for Better Testing. From determining roles and adapting to new needs, to developing T-shaped team members to make box shaped teams, and helping testers (and those interested in testing) develop more in depth thinking skills and work habits to be more effective. 
Section Three focuses on planning. No, not the massive up front planning of traditional development, but the fact that even the just in time and just enough process crowd does more planning than they give themselves credit for, and that the ways we do it can be pretty hit and miss. This section also goes back to the Agile testing quadrants and reviews how each has its own planning challenges. 
Section Four focuses on Testing Business Value. In short, are we building the right thing? Are we getting the right people involved? Do we have a clear vision of what our customer wants, and are we engaging and provoking the conversations necessary to help deliver on that promise? This section focuses on developing examples and using methodologies like ATDD and BDD, and identifying what we do know and what we don’t know.
Section Five places an emphasis on Exploratory Testing. What it is, what it’s not, developing testing charters, working with personas and tours, and working with the other varieties of testing needs and helping make sure our explorations also include territory not typically considered the realm of the explorer (such as Concurrency, Localization, Accessibility, UX, etc.)
Section Six focuses on Test Automation. Note, this talks about the concepts of test automation, not a prepackaged approach to doing test automation or a specific framework to use and modify based on examples, though it gives plenty of links to help the interested party find what they are looking for and lots more. 
Section Seven is all about context, specifically, what happens when we address testing in different organizations and with different levels of maturity and tooling? Version control, CI, and working with other teams and customers are addressed here, as are questions of Agile in a distributed environment. 
Section Eight is Agile Testing in Practice, and focusing on giving testing the visibility it needs to be successful.
Appendix A shows examples of Page Object based automation using Selenium/Web Driver, and Appendix B is a list of “provocation starters”. In other words, if you are not sure what questions you want to ask your product or your programmers as you are testing, here’s some open ended options to play with.
In addition to the aggregate of Lisa and Janet’s experience, there are dozens of sidebars throughout the book with multiple guest contributors explaining how they implement Agile in their organizations, and the tapestry of similarities and differences they have seen trying to make Agile work in organizations as diverse and different as each of the contributors.

Bottom Line: If you are brand new to Agile software development and Agile testing, this may not be the best place to start, as it
expects that you already know about Agile practices. Having said that, I didn’t see anything in this book that would be too hard for the beginner with team guidance to consider, implement and experiment with. However, if they have already read Agile Testing, and are hankering for more ideas to consider, then More Agile Testing will definitely help scratch that itch. Again, this is not a “how” book. This is a “what” and “why” book, but it has lots of great jumping off points for the interested Agile tester to go an find the “how” that they are looking for. As a follow on and sequel to an already solid first book, this is a welcome update, and IMO worth the time to read and reread.