I learned to develop software in the 1990s and started full-time work in the 2000s. I took time off to study other fields and returned to the practice in 2012, about the time this book came out. In the last 13-or-so years, I’ve noticed that the art of testing software has changed significantly. Twenty-five years ago, I started to code in an academic lab where we did our own testing out of necessity. In industry, I found teams arranged to perform tests. Now, it seems that testing has become a developer-only task again. I didn’t understand the backstory and am always interested in improving my skills. Thus, I purchased a few books on testing in general because I couldn’t find many newer works on testing that transformed the field. Most of the books, like this one, haven’t added a ton of new content since the 2010s unless it is related to security or automation.
Even though this book is 13 years old – an eternity in software development – it marked a historical culture change in software development. It taught that developers should be intimately involved in testing of their code and that testing code is not an intellectually inferior task. It sought to reframe the development-test cycle back into bettering the product. Indeed, the conclusion sought to get rid of the role of a pure test engineer in favor of a hybrid developer/tester approach.
This book focuses on managerial principles that implement this transition. It doesn’t address the nitty-gritty of testing practices and instead expounds upon how Google rearranged testing as a part of every developer’s workflow. It used to be that “test” and “dev” would cycle back and forth many times to fix bugs. Google’s then-new approach united the process and enhanced both speed of delivery and the quality of the product. This approach suited the world wide web better.
Few organizations work under the older paradigm anymore, and this book ushered in the change. The older paradigm helped develop software running on separated devices, but the Internet facilitated continual deployment where fixes could be shipped quickly with direct user feedback instead of lengthy testing runs. In turn, many former testers reoriented their efforts towards finding security holes and other software-related tasks. It’s interesting to trace this history and understand the drivers behind the culture change. I’m not sure understanding these nuances are necessary for most developers and especially not so for newer developers, but they enrich my knowledge of how coding practices have evolved in my lifetime.
How Google Tests Software
By James Whittaker, Jason Arbon & Jeff Carollo
Copyright (c) 2012
Addison-Wesley
ISBN13 9780321803023
Page Count: 281
Genre: Software Engineering
www.amazon.com