LogiGear

Book Re vi ew20How Google Tests SoftwareBy Adrian Woodhead, Last.fmHaving developed software for nearly fifteenyears, I remember the dark days before testingwas all the rage and the large number of bugsthat had to be arduously found and fixed manually. Thenext step was nervously releasing the code without thesafety net of a test bed and having no idea if one hadintroduced regressions or new bugs.When I first came across unit testing I ardently embracedit and am a huge fan of testing in various forms — fromautomated to smoke tests to performance and load teststo end user and exploratory testing. So it was with muchenthusiasm that I picked up How Google Tests Software‖—written by some of the big names in testing atGoogle. I was hoping it would give me fresh insights intotesting software at "Google Scale" as promised on theback cover, hopefully coupled with some innovative newtechniques and tips. While partially succeeding on thesefronts, the book as a whole didn't quite live up to my expectationsand feels like a missed opportunity.The book is written in an informal, easy to read mannerand organized in such a way that readers can read chaptersin any order or just choose to focus on the parts thatinterest them. One annoying layout choice is to highlightand repeat certain key sentences (as is often done inmagazines) resulting in one reading the same thing twice,often only words away from the original sentence. Thankfullythis is only the case in the first two chapters, but ithighlights the variable quality of this book — possibly dueto the authors having worked separately on differentchapters. How Google Tests Software isn't a book forpeople new to testing or software development. The authorsassume you know a fair amount about the softwaredevelopment lifecycle, where testing fits into this andwhat different forms testing can take. It is also largelytechnology neutral, using specific examples of testingsoftware that Google uses only to illustrate concepts.After a brief introduction as to how testing has evolvedover time at Google, the book devotes a chapter to eachof the key testing-related roles in the company: the'Software Engineer in Test' (SET), the 'Test Engineer' (TE)and the 'Test Engineering Manager' (TEM). SETs are coderswho focus on writing tests or frameworks and infrastructureto support other coders in their testing. The TEhas a broader, less well-defined role and is tasked withlooking at the bigger picture of the product in questionand its impact on users and how it fits into the broadersoftware ecosystem. These two sections form the bulk ofthe book in terms of pages and interesting content. TheTEM is essentially what the name says — someone whomanages testers and testing and coordinates these activitiesat a higher level within Google.The descriptions of each of these testing roles highlightsthe ways Google's thinking about testing has maturedand also shows how some of these approaches differfrom other companies’. There are also explanations of thetools and processes that people in these roles use andfollow and this for me was the most interesting part of thebook.Topics covered include: specific bug tracking and testplan creation tools; risk analysis; test case managementover time; and automated testing. Particularly of note arediscussions on using bots to perform testing of web pagesto detect differences between software releases, cuttingdown on the amount of human interaction requiredas well as the opposite approach — using more humansvia "crowd sourced testing" among first internal and thenselect groups of external users. The tools that Googleutilizes to simplify tester's jobs by recording steps to reproducebugs and simplifying bug reporting and managementsound very useful. Many of the tools described inthe book are open source (or soon to be opened) and areprobably worth following up on and investigating if this iswhat you do for a living.W W W . L O G I G E A R M A G A Z I N E . C O M F E B R U A R Y 2 0 1 3 ǀ V O L V I I ǀ I S S U E 1