The trouble with this book's title is that invites the humorous response "Google tests software?" which said in the right tone of voice is funny.

The point is that we all test software but do we make a determined enough effort? Google is big and produces lots of lines of code, many we never see in the outside world so yes it is of greatest interest to discover how Google tests its software and the line on the cover "Help me test like Google" is a promise worth investigating.

The trouble is as soon as you open the book you find too many slightly breathless self congratulations on having written the book at all. Testing isn't rocket science - or at least I don't think it is - perhaps the book will enlighten me and justify the initial hype.

The first chapter sets the scene and describes how Google takes testing seriously. It spends a lot time defining the roles of employees in testing: SWE - SoftWare Engineer, TE - Test Engineer, and so on. This is mostly about management organization and setting out mission statements.

Chapter 2 promises some technical details but it starts off with as much waffle as the first chapter then suddenly there is a short example with some code. It is welcome but completely out of place in the rest of the book. The chapter closes with a look at test sizes and interviews with some people involved in testing.

From here the book moves deeper into management and organizational issues. There are lots of fairly obvious statements that are effectively commonsense or motivational slogans - keep it simple, C is for component, and so on. There is some technical stuff hidden in there - bug metrics mainly - but the coverage is mostly of management issues - interviewing test engineers and so on. Some parts are of general interest like the Chrome OS test lab box out but at the end of the day this is not a book you want to read if it is testing technology and methodologies you are really interested in.

Overall, the style is readable but there is far too much self-congratulatory prose and cheerleading for Google. It eventually becomes tiring to keep being told how wonderful Google, and Google's approach to testing, is. It would be much better to lay the facts down and let the reader appreciate the awe.

If you are a test engineer, planning to become a test engineer, or are responsible for managing a test department then you will find this book relevant and maybe even informative. If you inhabit a more general space then it won't really tell you much about testing or creating better quality software.