Are you currently testing software in a project that feels like a train wreck in the making? Are you on a team that promotes “Agile,” but your developers aren't even doing basic unit testing?
During all this madness, has the thought ever crept into your mind: “Is this how successful software development companies like Google test software?” Well, wonder no more. This new book by James Whittaker, Jason Arbon and Jeff Carollo, How Google Tests Software, will answer once and for all your burning Google software testing questions.
Who the heck is James Whittaker?
Author James Whittaker is the test director at Google. In this informative book, he walks you through Google's full testing life cycle and shares his vision for the future of software testing. Whittaker has also worked for Microsoft, published a set of books about software testing and has been a professor of computer science at Florida Tech. It goes without saying that the dude knows his stuff.
The layout of the book
How Google Tests Software is 320 pages long, and is broken up in six main parts:
- Introduction to Google Software Testing
- The Software Engineer in Test
- The Test Engineer
- The Test Engineering Manager
- Improving How Google Tests Software
- Appendix (A Chrome OS test Plan, B Test Tours for Chrome and C Blog Post on Tools and Code)
What the Book Covers
The book covers, in detail, three of the main job positions at Google — feature developers (SWEs), test developers (SET) and user developers (TE) — and explains the ways in which the groups interact with one another. Also covered are the three types of testing done at Google, as well as the benefits and weaknesses of each.
How Google Tests Software is also filled with interviews with the individuals who are actually responsible for each concept that is presented. Google test best practices and common test documentation, RISK, how defects are tracked — all are presented in detail. And for those who dream of one day working as a test engineer for Google, the book even covers some common interview questions and skills required for the position.
Cool Concept – Test Certification
In my opinion, one of the most interesting portions of the book outlines Google's concept of Test Certification, which helps motivate its developers to take testing seriously. (If you've been testing for even a short time, you know how difficult this can be.) Another portion I found helpful was a summary of test-certified levels 1 through 5, as well as which types of tests should be set up in order to achieve each level.
Being a test automation evangelist myself, it was pretty cool finding out that the key to Google's testing is, in fact, automation! Now–before you get the wrong idea–when I say “automation,” I mean it in the broadest sense.
According to the book's authors, “if it can be automated and the problem doesn't require human cleverness and intuition, then it should be automated.” Having said that, they go on to point out that manual testing is still a big part of the overall testing strategy but even then, “testing is done under the watchful eye of automation.” They go on to explain how many aspects of the development process itself is automated–like the build process and the submission of bug reports.
The Death of a Software Tester – My Paranoid View
I will admit some things in this book were hard for me to hear. The authors' outlook on the future of testing at Google and the careers of testers in general is a real bummer.
On the other hand, however, it's a message that I think we in the test community need to hear, and a future we need to be prepared for.
Ultimately, the authors see the “test” title being removed as developers in an agile environment will be required to take responsibility for “quality testing” over time, which will simply become part of what a developer does.
Furthermore, with the adoption of iterative software development (which is the process of getting a product out to real users, regardless of limited functionality, which is how Gmail was developed), The manual testing of a product is actually being done more and more by the early (non-paid) users of a product.
If you're a manual tester this should serve as a wake-up call. For better or worse, this is a trend that I think will play out in virtually every company, so my advice to my fellow test engineers is to begin expanding your skill set—pronto—with an emphasis on bulking up your development chops.
This book is more of a case study then a practical book on software testing, which makes it an ideal read for someone who's already familiar with standard testing methodologies. Hopefully, you'll be able to glean some great testing advice to incorporate into what you're already doing.
And remember–this is a book about how Google tests software–so don't expect everything to be about universal testing principles. Bottom line: if you've read this far into my review, chances are you're seriously interested in learning How Google Tests Software—which means this book is for you.