They’ve done it again. Gojko Adzic, David Evans and, in this book, Tom Roden has written another 50 quick ideas book. And this one is equally good as the previous book on user stories. If not even better.
From the looks of it there’s a whole concept around these quick ideas and, fingers crossed, we can expect much more goodness like this.
This is my review after reading the book in the worst possible manner. I’ll tell you why. But even doing so I got so much out of this book and my tool belt expanded significantly.
I really like the approach of these short, focus, one-topic books, starting with Gojoks book on impact mapping. They don’t promise to be deep dives and total coverage but rather to give you ideas (well… that’s in the title even), be challenged and investigate further.
In this book, on testing, they have divided the ideas into 4 groups, brushing on different aspects of testing:
- Generating test ideas
- Designing good checks
- Improving testability
- Managing large test suites
One of the things that struck me is how far (agile) testing have progress during my relative short period interested in the field. This is a very sober and concrete look at the new breed of testers that want to be part in design, that takes failed tests as an opportunity to learn. We have sections on measuring test half times (how often do test change) in order to focus our testing efforts, there’s suggestions for how to involve and inform business users directly in creation of key examples etc. This is not your fathers testing and I like it!
I have a confession to make: I’m not really into testing. I’m a developer and very fascinated by agile testing but the early parts of this book touch more on organizations of test efforts and exploratory testing planning etc. That’s not my thing really. I read those parts faster. There’s a lot of good things in there, let there be no mistake about that, but it’s not my area of expertise and interest.
The two last parts I found extremely interesting and packed with battled-harden experiences that I sometimes found myself nodding in agreement too. Sometimes I heard myself going “Aaaaaah - I’ve never thought about that”. And sometimes I had to reread paragraphs a few times because it was really a new take on a situation I’ve been in.
And that’s typically how you get the experiences from experts served. Somethings you have experienced yourself and other things is things that helps your knowledge to take a jump ahead.
What I did wrong
The only real complaint you could have on this book is around the format. Yes I know. That’s what I said that I loved. I’m an enigma, what can I say?
Everything that I didn’t know about before left me feeling that I wanted some pages more on the topic. Or examples on how to implement this, although every Idea has a “How to make it work”-section that gives you a starter.
This is by design.
The book is not meant to be a complete overview. You should, as they point out in the intro, not read this as your first book. I might add: you should not read the entire book in one go. This is what I did. It left me hugely inspired to try things out, but also a little bit overwhelmed and scared that I will forget everything I read.
Instead I would suggest that you browse this book for overview and knowledge and then use it as a tool, hands-on, in your team. Keep it next to your team and look problems you run into up in the book. There’s a lot of pointers and ideas that can help you to get many, if not all, of the testing problems I’ve seen team run into under control.
I could not recommend the book more. Any serious agile tester should have this handy and get inspiration to move even further.
Thank you Neuri “Publishing” - looking forward to the next book. On retrospectives.
PS Where you the guys behind the 50 Shades of Grey book too? DS