How Google test software Reading Notes (2)

Chapter 3 The Test Engineer

This chapter mainly introduces Google's Te, Which is what traditional test engineers do every day? Rome was not built in one day, and Google was barely tested. However, it has always had the best team of engineers, such a technology-oriented company, skilled Talents are first-class citizens. However, with the explosion and change of the Internet era, they gradually realized that quality assurance and testing consciousness, means, and ways of thinking are also an art and a skill worthy of respect. Google can say that it has mined the definition of the SE (Test Engineer) role to the extreme.

There is no doubt that the Te role should focus on the real users of the system. At the same time, they also need considerable technology. Google's excellent Se has put forward the following criteria: can you evaluate system vulnerabilities? Can we provide accurate analysis on security, privacy, performance, usability, compatibility, and globalization? Can it be easily integrated with other systems or hardware? When the problem arises, which of the following are the effective cases to diagnose, debug, and collect necessary feedback data to help developers locate and solve the problem more quickly. Google is very concerned about whether se can become a product expert, whether it can have strong communication and cooperation capabilities, and use all Google resources across departments to solve various problems.

Google also has a common problem about test plan. Test plan is always created very early and then put aside. No one else will take the initiative to look at it. Google's solution to this problem is: the demand will change quickly, so the test plan should be updated at all times. It should describe the core competitiveness of the product, including the product architecture and component diagram, clearly describe the responsibilities of the product. In fact, this is also a shared vision of the team mentioned in Agile. When you can see a document that describes the most important information about the product at any time, this is an excellent test when setting up the same vision for it.
Plan. (Do not write in prose, do not write in sales promotion, it must exactly describe the test object and the final purpose of the test.) Google once tried a 10-minute test plan internally, the purpose is not to force everyone to write a test plan in just 10 minutes, but to urge everyone to put the most necessary information in the test plan, keep everyone willing to open it.

So how did Google's test case come about? This process is also interesting. First, they will define the product's responsibilities in terms of a product, called "component", and then use a series of adjectives to describe the features of the product, called "attribute ", then, when a component combines an attribute, a "Capability" that can represent a specific scenario is generated, which means what a product function can do. Based on this scenario, one or more test cases can be derived. For example: Google + profile,
Stream and circles (circles) are all component. Google + attributes include social, easy, relevant, and private. Examples of capability that can be produced by associating them:

• Profile (user profile) shocould be easy, so easy to enter and update and have it propagate.
• People (Google + users) shocould be social, so users can connect with user's friends, coworkers and families.

Based on this scenario capability, each of them can design several test cases. Google's test cases are derived from the combined capability of the Two-dimensional component + attribute.

Google's te also pays great attention to risk analysis, mainly in two aspects: the frequency of appearance and the impact. Test engineers have the responsibility to conduct risk analysis on any defects of the product, and even submit the results to those who are most concerned about it. Of course, the risk analysis is not only for bugs, but also for descriptions of areas that are not touched by the product's test coverage, rather than simply replying to a product that is of good quality or good quality. It is impossible for any product to go out of the release stage. No matter how many tests you perform, no matter how many tests you perform, risk analysis can provide a lot of reference for quality tracking and feedback analysis after the product is launched.

As Te is more focused on visualization and personnel selection, the points in the interview are different from those in set. Generally, Google will give you a test scenario. We hope that you can give full play to your subjective initiative. In the communication process, we will make the vague part of the scenario clearer and design test cases that are as comprehensive as possible, and puts forward the improvements that need to be improved in a scenario, even for fonts, colors, la s and other user experience. Of course, based on the background of Google products, the interviewer must also put forward his views on the scenario in terms of performance, internationalization, and cloud services.

Finally, Google manages the Te by pirate leadership. That is to say, just like a pirate in the pirate king, you can freely choose the sea area you want to go. Each Te can pursue a stimulating and free life. If you are not interested in this project, you can apply to join the project group you are most interested in. In fact, Google also encourages te to exchange ideas between various projects to learn more from different experiences.

Chapter 4 The test engineer Manager

This chapter describes how the test team is managed at Google. From the absence of tests, to the establishment of the test team, to the stability and maturity of the present, what changes and new cultures have been experienced.

This chapter focuses on interviewing many testing directors of different Google projects and asking about their experiences and dilemmas. For example, The Gmail test manager talked about Gmail's testing process divided into 20% of Exploratory tests, 30% of which were led by te for targeted function coverage tests, and 50% of which were covered by automated tests developed by set. They will also establish a user model based on the user type and feed back the data used during the test. The android testing manager talked about the need for te for a large part of their tests. To cover a large number of device models and hardware deployment, they concluded that exploratory testing should be conducted with a certain degree of purpose, rather than simply testing roaming, this purpose often comes from the ability to understand the source code changes and the associated parts, so te also needs to read a lot of code.

We also want to mention that many Google products use the "free testing" function to allow real users to help with the test. This is also the reason why many products are now directly releasing beta, so that users around the world can use the Internet to generate feedback, discover some bugs that are hard to find, and give some rewards. So far, many of Google's products are not still alive, such as wave and buzz, which are gradually replaced by Google + in the feedback of the market and the use of users. Imagine how big the loss would be if we blindly put a lot of tests into the wave and Buzz, but after we went online, we found that it was not what the user wanted most. Of course, there is another premise for users to perform free tests directly on the market, that is, there is a powerful feedback system to ensure that when problems occur, all the data to be diagnosed and repaired can be automatically submitted to the Development engineer, and the user's private data should not be collected. Because of Google's long-standing tool culture, many great online smart tools have been created. Therefore, Google can do a good job and other Internet companies will not know about it!

Chapter 5 Improving how Google test software

There is no best, but better. This chapter is basically a mixture of divergent thinking about what test talents the future software industry needs. What other aspects of the best test engineer can do better now.

For set, the ultimate trend is to be different from SWE, because they have exactly the same skill requirements. It is perfect to allow all engineers to program with a sense of responsibility to ensure quality. Of course, objectively speaking, the tool culture still requires a considerable number of engineers to focus on the development of efficiency tools for improving bug tracking, automated processes, and code defects. For Te, they must assume the role of the user to better utilize exploratory testing to discover internal and external defects of the product. What they need to focus more on is test.
Design, quickly build the Function Map, risk map and tours of the product, and clearly interpret the product from the user's perspective, so they must be a group of Google product experts.

In the future, the world will remain the world of the Internet, and there will be fewer and fewer native things. Both set and Te must understand that the construction of tests and future trends must be web-centric, with the least people taking advantage of web resources to do the most.

Ending Summary

After reading this book, I have reflected on the mistakes made in my previous work. It is true that Google has gathered many of the best engineers in the world, and its model may not be applicable to many domestic companies. The domestic testing industry is also messy. The boss always focuses on results rather than processes. However, engineers working as first-line runners should all reflect on how we can improve the efficiency of our team, using their respective technical advantages to simplify the process that allows machines and networks to do in software development, maximize the value of human thinking, and actively share experiences, jointly promote the improvement of the overall industry level. I am just an unknown little engineer, but I will do my best.

Excellent Resources in the Resource Book (most of them need to go through the wall)

• Google Protocol: https://developers.google.com/protocol-buffers/
• Google C ++ Style Guide: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
• Chromium automation framework pyauto: http://www.chromium.org/developers/testing/pyauto
• Native DRIVER: http://google-opensource.blogspot.com/2011/06/introducing-native-driver.html
• Google test blog: http://googletesting.blogspot.com/

Statement: indicate the source of the original document for reprinting.