How Google Tests Software

It is so exciting being part of an industry that is rapidly changing and won't be the same in 5 years or 10 years. Change means opportunity...opportunity not just to "fix" the pervasive misconceptions of what test is and how it should be done, but opportunity to cross into uncharted territory and come up with solutions that no one has ever tried before. That particular point - the idea of the future of test being open and uncharted - is incredibly cool. The book promotes ideas that are radical now but that eventually will become the norm - or they will be tossed as failures and replaced with something better. But the point is that opening up the discussion gives people license to think and experiment, to implement new things that could become great successes or massive failures. Either way, it's a step in the right direction, because test needs a lot of experimentation and empirical thinking right now to go from where it is to where it could be.I enjoyed the practicality of the book - it provided examples of real issues and how they were approached and solved, or not solved. I also enjoyed the lack of dogmatic "this is the only way to do it" mentality. I felt reading it that the authors were simply opening up and sharing, and that if someone was to come up with a great new idea to try, they'd give it a shake. Great pioneers and scientists care only about progress in their field, not about who gets the glory for the progress, and I felt like that's what this book was after - progress.Great book to get you thinking and learning, and where there are gaps or open-ended questions, this is the territory for opportunity.

This book is is a rare peak into the development and testing culture at one of the largest software producers today. Filled with insider commentary and interviews, the book presents Google's approach to integrating testing into development. Case studies such as the Chrome browser, Chrome OS, Android show that there isn't a one true approach to quality, and show how and why people at Google made tradeoffs between automation, exploratory testing, pushing testing into development, informal checks and formal plans.I found the discussion on scaling testing and integrating developers and testers particularly interesting as it offers a lot of good advice on how the roles of developers, testers and test managers changed at Google. If you've recognised your organisation in my presentations at StarEast and Oredev (Sleeping with the enemy) or Eurostar (Death to the testing phase), you will surely find a gold-mine of great advice on how to better engage testers and developers into a whole team approach. My top three picks for ideas that that should inspire you are:Test Certified program that got entire teams interested in building quality inAwarding people readability levels for important technologies and relating that to roles they play in code reviews and commits, effectively building something as effective as opensource committer levels to scale out development to a large number of peopleSoftware engineer in test role and career path discussionsDevelopers, testers and managers working for larger organisations will surely find the ideas on managing test plans interesting, in particular the ACC Matrix. If for nothing else, you should read this book and keep it close because it sheds light on this innovative practice. I first heard about this technique two years ago at a conference, and since then I've been fortunate enough to work with several companies that let me try it out, with fantastic results. I think ACC is one of the most promising value/risk based test management tools today, and it has helped several of my clients re-evaluate how and what they test and reduce their investment in testing by 80-90% while getting a better return on the time spent. So far, there's been very little material published on how Google actually uses the technique, and this book will provide a valuable reference for many people out there trying to implement it.It's a bit unfortunate that the level of technical detail varies greatly, so I'm afraid that low-level technical stuff might put off managers from reading the more important high-level aspects on scaling. I give this book 4 out of 5.

I saw James Whittaker speak at STAR West in 2011, and he gave a keynote titled "Test Is Dead". His talk was essentially a teaser for How Google Tests Software that he co-wrote with Jason Arbon and Jeff Carollo. The premise of the book is that testers need to have engineering skills (sometimes to an equal extent as software engineers) in order for the testing discipline to reach first class citizenship on equal footing with development.The argument is aligns well with the movement toward agile software development methods. The book goes on to breakdown testing responsibilities for software engineers (SWEs), software engineers in a test role (SETs), and Test Engineers (TEs). Almost half of the book deals with the roles and responsibilities of the TE, and in the Google model, they do have a higher-level role in testing. In essence, it breaks down like this:* SWEs write unit tests for the software they write* SETs write tools to enable testing without external dependencies and write automated functional tests* TEs coordinate the overall testing activities for a product and focus on the user by doing exploratory testingIn addition, the book also outlines a number of tools (many of which have been open-sourced) that Google uses for testing in the context of these roles. The majority of the content focuses on web applications (it's Google after all), and some of the ideas won't apply if the majority of your development is for internal customers to your company - since you probably have user training and rules about frequency of release. However, I would say that you could apply 80% of the ideas in any context and probably adapt at least 10% (if not more) of the others to your situation.Also, there is also a chapter on test managers and directors that has interviews with a number of prominent Googlers. Then, the book ends with a discussion on the future of the SET and TE roles at Google along with some of the errors Google made.Google embarked on the transformation in 2007, and my company is currently trying to do something similar. I hope to be able to leverage these ideas in the months ahead. I recommend it to anyone who is or expects to be involved in such a change. I would also recommend it to any tester in an agile development shop. You may not agree with everything in the book, but tells of the future (if not the present) for much of the software testing industry.

Quality of the paper in the book is not good.

I learned a great deal about testing from this book. Googlers are some smart folk and they give lots of great insight about how and why they put so much importance on testing. There's even tips on what they're looking for in interview candidates. Highly recommended.

I am quite some time around in the Software quality and Testing business, and I have seen and read a lot of books about that topic: Structuring by V-Model, different analysis and design methods, testing as part of a process model and so on.The issue that I had with most, nearly all of them was: Why start testing at the end?Why not prevent defects instead of having to find them? And be made responsible in case, they slipped through.This book is different, like the company.They try to catch a defect before it can make its way to the code, they will rather put off functionality, if it is not properly tested, and so on.All things, that I personally think, make so much sense, and which are not followed by the PMs and Devs of the current business.As I said before, this book is my favorite at least for this year. If not for the decade.It motivated me to get back to programming, to be able to facilitate automatic testing to the dev people to overcome the pain for them. Great!

I wish my company had the same approach towards test automation! Very good book that inspires and shows that 'it can bo done'! Many practical examples of how testers work, what problems they solve and how their job contribute to the quality improvement policy.

Google dudes using TLAs to explain why everything they do is better. It boils down to "we only hire genius-level dudes: even the janitor is like, william hunting"... that said, this stuff is Good To Know