How Google Tests Software?
Last week software testing specialist of Ardecs company talked about topic: "How tests in Google?", based on material of the book "How Google Tests Software" of 2014.
The book "How Google Tests Software" about Google testers who came to understanding that there is need to change, about how they were building up new processes, what they achieved and how they vision further development of testing processes.
Test approach of Google is paradoxical at first sight: there are less specialists in a separate testing group in the whole company, than in many competitor companies in a single development team. In Google the responsibility for quality in on those who write a code. Every developer in Google is a tester in a sense, and the quality is a problem of the whole team. On the one hand, quality is not created by testing; on the other hand, it is impossible to make a product of the high quality without testing. It is important to stop considering development and testing discretely. Testing aligns with development: testing is not a separate thing: it is an integral part of the development process. Testing alone cannot raise the quality. The recipe of raising the quality is to mix development and testing until indiscrete mass.
At Google, this is exactly their goal: to merge development and testing so that you cannot do one without the other. The key here is who is doing the testing. Because the number of actual dedicated testers at Google is so disproportionately low, the only possible answer has to be the developer. The reason Google can get by with so few dedicated testers is because developers own quality. If a product breaks in the field, the first point of escalation is the developer who created the problem, not the tester who didn’t catch it. This means that quality is more an act of prevention than it is detection. Quality is a development issue, not a testing issue. At Google, testing is aimed at determining how well this prevention method works.
Google selected three main roles of a command:
- The software engineer (SWE) is the traditional developer role. SWEs write functional code that ships to users.
- The software engineer in test (SET) is also a developer role, except his focus is on testability and general test infrastructure. SETs review designs and look closely at code quality and risk.
- The test engineer (TE) is related to the SET role, but it has a different focus. It is a role that puts testing on behalf of the user first and developers second.
Instead of distinguishing between code, integration, and system testing,Google uses the language of small, medium, and large tests (not to be confused with t-shirt sizing language of estimation among the agile community), emphasizing scope over form. Small tests cover small amounts of code and so on. Each of the three engineering roles can execute any of these types of tests and they can be performed as automated or manual tests. Practically speaking, the smaller the test, the more likely it is to be automated.
The implication is that Google prefers to release and give the product to the user as quick as possible in order to receive the prompt feedback and make corrections.
