How Google tests software-Part III

Author James Whittaker, former Microsoft architect, is the author of several books in the "How-to-Break software" series, the current Google test Engineering director, who recently wrote a series of articles about how Google tested software, the third part of its series.

In the first two parts of the article, a lot of people raised questions in the comments. I didn't forget them. Hopefully most people will find the answer in the rest of the article. I'm still starting the subject of this article.

At Google, quality is not equal to testing. I believe that is true in every place. The old adage that quality is not tested is no more true. From cars to software, if they had problems at first, they would never be fine. Ask any car company that has been forced to recall a lot, and how much it costs to cover up the quality problem.

However, the factual situation is not as simple and precise as this sentence. Although quality is not a test, we have the same evidence that, without testing, you can't develop anything with quality. How can a person decide that your project is of high quality without testing?

The simplest solution to this dilemma is to prohibit the opening of the development work and test it in the spirit of independence and freedom. Testing and development work needs to be done synchronously. Write a little, test a little. Write a little more and test a little. A better approach is to make a test plan, or to do it before you develop it. Testing is not a standalone work, it is part of the development effort, along with the entire development process. Quality is not equal to testing; for quality, you need to combine development work and testing, stirring them up until you can tell me.

At Google, this is our clear goal: to integrate development and testing, you can't do any work alone. Do a little, test a little. Do a little more and test a little more. The key is to see who is doing the test. Because at Google, full-time testers are surprisingly small, so the only way to do this is to use the developer. Is it more appropriate to test those who actually develop these programs? Is there a better way to find bugs than the author of the program? Who has more desire to avoid bugs when the program first writes out? The reason Google has so few full-time testers is that developers are responsible for quality. In fact, a team that insists on using a large testing facility usually develops something that is problematic. The testing facility is large, and this is a signal that the coding/testing work is in harmony with the problem. Adding testers does not solve any problems.

This means that quality measures should be more of a preventive action than a discovery process. Quality is a development issue, not a test issue. by integrating the testing effort into the development process, we have greatly reduced the chance of error for someone who is supposed to be writing a lot of problematic code. We not only avoid a large number of customer-side problems, we are also very effective to reduce the testers put forward, is not actually a bug. At Google, the goal of testing is to check that these prevention efforts are running efficiently. The Test Engineering department has been looking for evidence of the combined performance of the software engineer as a bug creator and the test software engineer as a bug-maker, and once the method is in trouble, they will sound the siren.

This combination of development and testing can be seen everywhere, from code review comments to "What about your test?" "A poster for the best test practice for developers in the toilet – this is our notorious toilet testing guidelines. Testing is essential in development work, and the marriage of development and testing is the process of quality-breeding. The soft worker is the tester, the test software is the tester, and the test engineer is the tester.

If your business also has this type of combination, please share your success experience and challenges. If not, then this is an opportunity to bring benefits to your business: Draw an equal sign between the developer and the quality. You've all heard such an old story: chicks are happy to give their own strength for a salty pig's leg and egg breakfast, but what did the pig do wrong? It is true that ... Go and hum to your developers to see if they can get their hum response. If they're making a giggle, that means there's a problem between you.

How Google tests software-Part III