Top positive review
A Great High Level Starting Point
June 25, 2013
I picked up this book when I took a job that required building a QA team from the ground up in an agile development environment that had already been developing for six months.
I say that because the usefulness of this book has a lot to do with your organization, and what your starting point is. If you are working on a development team starting from scratch then this is a must read for any lead or manager involved. There is a ton of high level conceptual information in here that will help you draw out an outline of what you need to think about in terms of testing over the next few months. This runs from what broad categories needs to be tested (Security, -ility, GUI, etc.) to who is responsible for automation (Unit test, API testing, etc.). I can honestly say that sticking to these concepts will help you make a better product faster.
Here's the downside. If you are coming in midway through a project then get ready for the battle of a lifetime getting this stuff implemented no matter how much sense it makes. Unit testing, as an example, is constantly brought up throughout the book, and that is not something that you can get up and going with a snap of your fingers. Especially if you have to educate development on how to do it. This book provides little support in that sort of area, and, honestly, that is most likely the scenario that most people in QA will run into. I have been in QA for ten years, and every place I have worked either had no unit testing at all or the had just enough to claim that they did.
The reality is that Agile Testing in this book equates to Test Driven Development with QA support. That mean QA is responsible for a lot of solution, end to end, and customer requirement verification testing, but very little feature and functionality testing since that is expected to be done in unit testing. If you are in QA and you need to read this book then you almost certainly do no have that already, and need a book that tells you how to do it.
So, anyways, this book is worth reading if you are just starting out, but make sure you are reading it with development and project management as well. If you are not just starting out then In my opinion these steps are required:
1. Get acceptance from Management, Dev, and Project Management that your current model is not sustainable, and that resources will be allocated to changing that.
2. Read this book with all of those involved.
3. Meet up and list out what the book recommends, where you are strong, and where you are weak.
4. Use that as a starting point to find other books and resources to strengthen up your weak points.
5. Make sure that management makes the success of these changes part of everyone's job responsibility, and emphasizes it as part of performance evaluations. Period.
In my experience, if you can't get the five steps above completed then you might as well throw this book out the window, because you'll waste a bunch of time implementing QA practices that will fail miserably due to their reliance on a non existant foundation. Step five is the real key. Otherwise you get one of the following:
1. "Great Idea!" with no action following
2. "You're right, we need these changes," and then an expectation that QA will be responsible for all of them. Including things like forcing individual dev's to do unit testing.
The weakness in the book is that it doesn't really address the needs of QA in terms of helping you get through those five steps.
If you use this book as a planning tool then you will be in good shape and the value is absolutely there. It is a quick and easy read, gets the concepts across in a way that pretty much anyone can understand, and does so convincingly. Just don't go in expecting it to answer all your problems without some supplemental reading. You will need to read up on automation and unit testing frameworks and test driven development.