Wes Maldonado: Data Junkie

I’ve writen about being an SDET before and now here is Google’s take on the definitions of Quality Assurance (QA), Quality Control (QC) and the roll they call Test Engineering.

Here at Google, we tend to take a third approach that we call Test Engineering. We look at this as a bridge between the meta world of QA and the concrete world of QC. Our approach allows us to ensure that we get the opportunity to think about customers and their needs, while we still provide results that are needed on day to day engineering projects.

Our teams certainly work with Software Engineers in QA and QC roles, but we also work with teams to ensure that a product is testable, that it is adequately unit tested, and that it can be automated even further in our teams. We often review design documents and ask for more test hooks in a project, and we implement mock objects and servers to help developers with their unit testing and to allow our teams to test components individually.

We put an emphasis on building automated tests so that we can let people do what people are good at, and have computers do what computers are good at. That doesn’t mean that we never do manual testing, but instead that we do the “right” amount of manual testing with more human-oriented focus (e.g. exploratory testing), and we try to ensure that we never do repetitive manual testing.

The difference between QA, QC, and Test Engineering

If this post interested you, you should check out the positions open at my company in Seattle, WA. We have a White Box QA/SDET position, Black Box QA, and Java Developer positions available.