Google's Innovation Factory

Google's Innovation Factory (and how testing adapts)

Now that ICST 2010 has concluded, I'm going ahead and posting the keynote paper and the slides. Enjoy!

Patrick Copeland

Let me know if you have comments or questions.

Here's a link to the paper. They are semi-complementary.

Permalink | Links to this post | 9 comments  

Google is hiring SETs

Friday, March 12, 2010 8:56 PM

Drop me a resume and a brief note if you're interested in joining Google as an SET. email: test.eng.hiring@gmail.com. Thanks -- Patrick Copeland

When we hire people we look for folks with a "testing DNA." These are people who are great computer scientists at their core, but also are very curious, love software, and are passionate about test engineering. People who have those characteristics tend to pursue challenges and continue to learn. Are you one of us? We have positions all over the US and the world.

What is a SET?

At Google, Software Engineers in Test (SET) develop test frameworks and build robust, scalable, and effective tests. SETs spend a majority of their time coding in either C++, Java, or scripting in Python. A SET is a software engineer, a core developer, who has a passion for test engineering.

How is testing done differently at Google?

• Literally within milliseconds of a code check-in, our build process will automatically select the appropriate tests to run based on dependency analysis, run those tests and report the results.
• By reducing the window of opportunity for bad code to go unnoticed, overall debugging and bug isolation time is radically reduced. The net result is that the engineering teams no longer sink hours into debugging build problems and test failures.
• Development teams write good tests because they care about the products, but also because they want more time to spend writing features and less on debugging.
• Testing teams focus on higher abstractions, like identifying latencies, system or customer focused testing, and enabling the process with tools.
• SETs avoid becoming codependents within this system and generally do not write unit tests or other activities that are best done by the developer.

More about SETs

• Our SET’s spend time developing code to prevent bugs. Google has a strong cultural emphasis on developers improving quality (i.e. unit tests, code reviews, design reviews, root cause analysis). We want our engineers to spend their time innovating - not fixing bugs.
• SETs enable products to launch faster. They have great influence over internal processes and how developers write code.
• One of Google's less understood capabilities is our massive distributed computing environment. The testing groups exploit this infrastructure to do huge amounts of work very quickly and elegantly.
• For someone who wants to learn and grow as an engineer, the uninhibited access to the entire code base is a unique opportunity.