One good thing about the title, it should mean that testers read the book. One bad thing about the title, other roles might not. But they should. This book provides a particularly good introduction and overview to the Agile process from a ‘test’ perspective.
( amazon.co.uk | amazon.com )
Anyone that has worked in an Agile environment for some time will read the book and relate very easily to the stories, philosophies and practices described – your danger is reading too fast and skipping over chunks that you can learn from.
Anyone not familiar with an Agile environment will get a massive head start after reading this book, you will not have to learn everything the hard way and you will read about many options open to you.
It does seem, from various questions in forums and the generally feeling of writing on the internet that many testers find it difficult to know what to do in an Agile environment. This book will answer many of the early questions and help the tester more confidently approach the project and engage with the other team members with the aim of creating a ‘whole team’ approach to testing.
I recommend this book unreservedly for testers new to Agile projects.
Project Managers would gain a lot from reading this as I found this book one of the most rounded and pragmatic books on Agile that I have read.
Developers would gain from understanding what testers do when they have their heads down coding, or even possibly what the testers ‘should’ be doing.
Agile presents a learning environment for everyone on the project so if your testers have not read this book – try subtly nudging them towards this book by dropping it with a resounding ‘thud’ on their desk.
Lisa and Janet have covered a lot of ground in the book and as a result it has bucked the recent trend for thin books. So you certainly feel like you get value for money, I just hope that most readers manage to work through it because the authors have taken great pains to build on the material throughout the book and cover some of the more subtle points of engagement towards the end.
Agile projects can differ greatly from each other and can offer different contexts for the tester. Each project starts at a different stage of learning and knowing when to push for certain techniques and tackle certain issues can prove hard to judge. So the authors have had to tackle the issue of providing generic advice in a way that the tester can make use of it when they most require it. Lisa and Janet have done this by adding short experience memories throughout the book – theirs and other Agile practitioners. They have provided generic advice and options. They also encourage the reader to experiment, to try out the practices, drop them if they don’t currently work – with the knowledge that they might work at a later stage on the project, and that sometimes they don’t need to use that on a project.
I really love constant reminder that Agile revolves around the team working as a team and that the testing on an Agile project requires the same team based approach because too many projects and teams that I have worked on split into their own disciplines even though we know that we will only succeed when the whole team conducts the testing, and when the testers get involved in the analysis, design and coding. Fortunately the book presents experiences of how to ‘gel’ the team – all of them communication based and all of them workable.
Very often in book reviews I attempt to summarise the chapters and pull out key points. Sometimes I find this very easy to do because the book actually has very little content. I will not attempt to do that for this book. Spread over 21 Chapters and more than 500 pages I found too much of relevance so I urge you to read it for yourself.
And having read the book, it then becomes a useful dip in and out reference, reminder, and paper based mentor on your desk.