Test Engineers @ Google
January 14th, 2013 | by Anthony Vallone | published in Google Testing
At Google, we’re very big into highlighting individuals’ strengths and using them to make teams and products better. However, we frequently get asked “What do Test Engineers (aka TEs) do?” I pause when I get this question since it’s hard to speak for my peers – I test Google Maps rendering, which is just one small portion of what Google’s Test Engineers test.
In order to get a clearer picture of what Test Engineers are responsible for, I chatted with three of my colleagues. We were able to identify the underlying Test Engineers’ similarities, while highlighting the differences.
So what common themes do Test Engineers specialize in at Google?
Test Engineers need to become a “go-to” person for how their product works and integrates with other Google products. (You aren’t expected to have this before working with a product, but you need to figure out how to become one on any product you work on!) TEs need to understand use cases and contracts with other services, products, and features. We aren’t expected to write unit tests for other engineer’s code; instead we ensure product quality on the functional and integration aspects of the product.
We’re flexible:
Test Engineers are required to switch tasks and re-prioritize frequently. From unplanned catastrophes, to shifting launch calendars, to people asking us questions, our work is filled with interrupts. We determine how to ensure quality in the face of the interrupts.
We also modify our tests based on the pace of the development and understand that there is no one right way to test a product. Test Engineers adapt tools to meet their needs and understand when a tool just can’t get the job done.
We’re clear communicators:
We have to be able to communicate via test plans, design docs, bugs, email and code. Every day we work with a wide variety of people in different roles: Software Engineers, Software Engineers in Test, Product Managers, Usability Researchers, Designers, Legal Counsel, etc. We need to address these different audiences to make sure we’re either gathering the information that will help us build better strategies or presenting feedback that will help influence the product.
We’re good at coordination:
We are people who use our “in between the product and user” status to coordinate integration testing efforts between products. We may coordinate manual testing efforts by our manual testers; or we may make sure that test gaps are being addressed by “someone” (Test Engineer, Software Engineer in Test, or Software Engineer). We put our product knowledge and communication together with a bit of coordination and make sure that bugs are looked at and the product is getting tested hourly / daily.
We have impact:
Google Test Engineers have big impact. We hold responsibility thinking of ways that our products could fail in “real scenarios”; and then we add tests to make sure that the worst won’t come to pass.
How big is this? Well, in my case, I’m responsible for making sure Google Maps represents a map that is useful to my relatives in the middle of rural Montana as well as my friends living in London, Paris or Sydney. When you add to that the billions of other users in different regions, speaking different languages and using the map for different reasons, I know that my testing is impacting their ability to get around and find out information about the physical world around them safely.
We code:
The other most common question is “Do you write code?” The answer is yes; Test Engineers at Google do code.
The three aspects that generally differentiate what a Test Engineer does day-to-day depend on the following:
Everyone is different and every TE has different passions, strengths and areas of expertise. Thankfully, Google’s a big enough company that many different areas of testing are available, and we gravitate to testing products we like. All TEs start with core competencies in testing, coding, and algorithms. How a TE applies this knowledge varies.
The Type of Product:
Desktop, web app or mobile? Frontend or backend? The technologies that our products use and run on create a lot of variation in what and how we test.
The Product’s History / Lifecycle:
Early concept products don’t resemble those that exist in production. And the amount of testing that a product already has will determine what testing the TE is focused on. We work creating a test roadmap that parallels the product’s development cycle and addresses any testing gaps.
If you still want to know what the day in the life of a Test Engineer entails, we’ll never be able to give you a general answer for that. Instead I suggest that you check out what Alan Faulkner is doing or ask the next Google Test Engineer you meet.
Interested in joining the ranks of Test Engineers (or Software Engineers in Test)? Check out http://goo.gl/2RDKj
About the Contributors:
Albert Drona has been at Google for 5 years and is currently working on Google Maps for Mobile.
Jatin Shah has been at Google for 9 months on Google+.
Mohammad Khan has been at Google for 7 years and is currently working on Google+ releases.
About the Author:
Yvette Nameth has been at Google for 5 years and is currently working on Google Maps rendering.
