Three Things I Learned about Testing at Google that Might Surprise You
By: James A. Whittaker
When I first set out to write How Google Tests Software, I was a test engineering director over a number of Google products including Chrome, Maps, and Cloud. My goal was to document all the testing goodness that was going on inside the company, and although I accomplished that goal, what I really learned was far more cathartic. By the time I finished the book, Google had undergone a major transformation from a centralized testing organization to a distributed test model where testers reported to their development managers.
In retrospect, the centralized testing model described in the book was the right approach for a growing Google. The power of centralization meant that Test could take on a more visible role within the company, share resources and experiences among teams, and have enough critical mass to make quality something hard to ignore. It worked, and the book describes how this organization was built and how it executed on the massive scale that is Google. There are lessons here that every company from startups to medium and large organizations needs to hear.
But in the end, the test organization at Google grew too big and wielded too much power. Battles between product groups demanding more testers and the test team denying them based on the logic that too many testers were a crutch were legendary. “Test” became a subculture within the company and this brings me to my first lesson:
1. Whenever testers identify more with their discipline than with their product, it’s not healthy
I found an old t-shirt in a schwag closet at Google that sums up this attitude: I TEST THEREFORE I AM. This is categorically unhealthy. Teams at Google where testers celebrated their bugs were the least functional teams we had. Please destroy these shirts. Throw away the “top bug” awards and have your team -- the whole team -- get behind the product. You know you are successful when every PM, developer, tester and technical writer cites the product and not their role when asked, “What do you work on?”
... to read more articles, visit http://sqa.fyicenter.com/art/