Reading Notes: Google’s Software Testing Philosophy – Role Division and Quality Integration

Preface – The book “How Google Tests Software” (first published in 2013) is considered essential reading for software testing, but many of its ideas may not directly apply to Chinese contexts; readers should discern which concepts are adaptable.

The series of notes covers the first three chapters of the book, offering personal reflections and encouraging readers to form their own understanding.

Key Insight 1: Success Factor – Google’s first advice on its success is “don’t hire too many testers”. This challenges conventional testing management thinking and, after reading the early chapters, appears justified from Google’s perspective.

Key Insight 2: Quality Is Not Equal to Testing – Quality is created during product design and development, not merely discovered by testing. Post‑development testing can only detect or describe existing quality; it cannot improve it. When quality issues arise, responsibility lies not only with testers but also with product designers and developers, requiring process improvements.

Testing, however, remains essential to simulate real scenarios and provide feedback for development.

Key Insight 3: Integrated Development and Testing – When development and testing are blended like ingredients in a blender, true quality emerges. Google advocates a tightly coupled development‑testing pipeline where code submission automatically triggers tests, and failed tests are promptly analyzed to give rapid quality feedback.

Google’s Role Division – The book defines three roles:

SWE (Software Engineer) – traditional developer who also writes test code and maintains automation.

SET (Software Engineering Test Engineer) – a developer‑focused role responsible for testability, frameworks, and providing quality advice.

TE (Test Engineer) – quality consultant from the user perspective, acting as product expert and risk analyst.

In contrast, typical domestic teams separate developers and testers, with developers rarely handling extensive testing and testers covering most SET and TE responsibilities.

Comparison with Domestic Practices – Domestic roles often look like:

Developer – similar to SWE but without testing duties.

Test Engineer – combines SET duties, much of TE, and some SWE testing tasks.

Product Manager – may perform parts of TE (acceptance testing).

Reasons for the gap include insufficient technical capability of test engineers, lack of quality awareness among developers, and cultural differences.

Conclusion – Google places high emphasis on quality, expects developers to share quality responsibility, and integrates testing into development. While the model is insightful, organizations should assess their own context before adopting it.