Personally, one of the most fascinating things that is currently taking place in the software industry is the speed and frequency at which companies like Google, Amazon, Netflix etc. ship their code to production.
These companies are long past the age where a production deployment was a major milestone, and required a whirlwind of activity by many different teams to accomplish.
However, the majority of other companies are still a few years behind these players, and production releases are still a big deal, and are a quarterly event at best.
I have always been curious about how companies such as Google manage testing because in almost every project that I have worked on testing has been this huge monolithic activity that has given everyone headaches. And given how much time testing takes I couldn’t imagine how someone ships their code multiple times a day to production?!
How Google Test Software is a very insightful book into the leading practices and philosophy behind Google’s testing. It is written by people who have been deeply involved in testing for Google, and I’ll paste a little snippet about the authors here to give you a sense of their background and expertise on this subject.
James Whittaker is an engineering director at Google and has been responsible for testing Chrome, maps, and Google web apps. He used to work for Microsoft and was a professor before that. James is one of the best-known names in testing the world over.
Jason Arbon is a test engineer at Google and has been responsible for testing Google Desktop, Chrome, and Chrome OS. He also served as development lead for an array of open-source test tools and personalization experiments. He worked at Microsoft prior to joining Google.
Jeff Carollo is a software engineer in test at Google and has been responsible for testing Google Voice, Toolbar, Chrome, and Chrome OS. He has consulted with dozens of internal Google development teams helping them improve initial code quality. He converted to a software engineer in 2010 and leads development of Google+ APIs. He also worked at Microsoft prior to joining Google.”
The biggest takeaway for me from this book was the focus on automating tests, and on treating testers and developers the same way. The idea that a tester and a developer should have the same skills because the tester will ultimately write code to automate tests was new to me, and one that made a lot of sense if you think about test automation as one of the key things that will enable consistent quality and speed to market for your product.
Another wow moment for me was reading that in Google people raise bugs in the automated tests, and treat automated tests just as they would treat the code itself!
I also really liked the last chapter on the role of test engineers and test managers in the future, and how the authors see this shaping up. It is a little bit of a dire forecast if you are in this role yourself, but I do the see the industry tending in the direction of wanting fewer specialist testers and therefore test managers, and instead the mindset is shifting towards quality being the responsibility of every developer, and quality being baked into the development process itself.
Overall, I quite liked the book; I would however say that there seems to be a lot of repetition in the book, and it could have been a lot shorter without losing any of its key messages. That being said, there’s a lot to learn from this book, and was a definite worthwhile read for me.
Leave a Reply