How Google Tests Software

relatively low numbers of Google SETs isn’t because Google has created a magic formula for productivity, but more of a result of adapting our engineering practice around the reality that the SET skill set is hard to find.

Google SWEs are feature developers. Google SETs are test developers. Google TEs are user developers.

Reuse is rewarded far more than complexity or cleverness.

One thing is for sure: Testing must not create friction that slows down innovation and development. At least it will not do it twice.

Instead of distinguishing between code, integration, and system testing, Google uses the language of small, medium, and large tests

“Quality cannot be tested in” is so cliché it has to be true. From automobiles to software, if it isn’t built right in the first place, then it is never going to be right. Ask any car company that has ever had to do a mass recall how expensive it is to bolt on quality after the fact. Get it right from the beginning or you’ve created a permanent mes

For these types of tests, the person who writes the code and understands it best is the one who is most qualified to test it.

Google tries hard to develop only products that users will find compelling and to get new features out to users as early as possible so they might benefit from them. Plus, we avoid over-investing in features no user wants because we learn this early.

Manifestations of this blending of development and testing are inseparable from the Google development mindset, from code review notes asking “where are your tests?” to posters in the bathrooms reminding developers about best-testing practices.

The question a small test attempts to answer is, “Does this code do what it is supposed to do?”