How Google test software Reading Notes (1)

I haven't written a blog for a long time, because I have been reading the "how Google test software" book. I will watch dozens of pages no matter how late I go home every day, supplement the spiritual food. Now that I have finally finished reading it, I want to extract some of my feelings and remember it is always unreliable.

Chapter 1 Introduction of Google software testing

There is a very important point: quality is not equal to testing. If we say we have to give quality a definition: quality is generated when development and testing are mixed together and cannot tell each other clearly. Therefore, the article advocates code a little and test what you built, so that the gradual process can produce stable quality. In terms of quality, preventing problems is more important than discovering problems. Quality is more of a problem for developers than for testers. By integrating the testing work into the development process, we can reduce the error opportunities of those who are rich in bugs and avoid the use of a large number of end users, crash can also greatly reduce the number of bugs reported by testers.

So how does Google define test engineers? Some engineers are responsible for making other engineers more productive and more quality-minded. In addition to testing engineers, Google also has a role called set, that is, testing and development engineers. They focus on the potential risks in code quality and code architecture, and they will reconstruct unit testing, builds a testing platform and develops user-friendly automated tools. In fact, it is very important that the so-called automated tools are not only used for automated testing, but the automation that can be used in all aspects of the R & D process to improve efficiency, even those used by the HR department, applicable to product managers, or users can use tools that can improve efficiency and make the Google product development process smoother, they will try to do so, and continuous improvement.

So how did Google engineers spare time to make and maintain so many tools for improvement? In Google, there is a 20% culture for innovation. Every employee is allowed to take 20% of the work time out to do whatever he wants, it is equivalent to spending only four workdays a week on your own work. In that 20% of the time, Google's engineers often joined forces to initiate various tool projects based on their interests and areas of expertise, in the end, almost all open-source sources are available to the world, because they believe that people's thinking is infinitely broad. The best way to brainstorm is to open-source and welcome everyone to download and improve. In fact, for example, Selenium
The excellent framework of WebDriver attracts excellent engineers from all over the world, and almost all of the rapid development needs to be included in W3C Web automation standards.

In addition, this chapter also explains the classification of Google's testing work. They prefer to use simple small, medium and large to define the test type, the size class words indicate the size of the test, that is, the scope of the Code that it can cover. In the traditional sense, small is equivalent to unit testing, covering only a single piece of code, while medium combines some associated code fragments for testing, which is similar to integration testing, the real simulation of user behavior is the end-to-end large test, similar to what we often call a system test. In the small and medium tests focusing on code snippets, Google uses fake and mock techniques to simulate environmental factors and data objects.

Chapter 2 The software engineer in Test

This chapter describes Google's set, which is the role of a test and Development Engineer. Many Google's set has been transferred from development. They are interested in testing and have a talent in quality assurance. They are usually willing to share and create tools to improve everyone's efficiency. We need both enthusiasm for testing and strong coding technologies. Such talents are hard to find on the market, finding from development engineers is often a more reliable approach. I have always felt that computer technology, whether used in development, testing, or somewhere else, is designed to make people's lives better, why bother developing or testing these roles!

At Google, set and SWE (R & D engineers) work closely together, and their work even overlaps many parts. Although the traditional concept is that the division of labor in engineering projects can result in efficiency. However, the demand for the Internet IT industry is changing rapidly, with information burst and market opportunities rapidly disappearing. The quality of software is precisely through this inseparable overlap, only in this way can the entire team be truly responsible for this. The division of labor is too clear, and many people will be introduced without reason. No one wants to admit that they are not doing well for some problems. SWE will write more small
Test code, and set will write more mock and fake Environment Code. Google's project generally starts with an agreed interface, starting with mock while white box, and set enough challenges and milestones in advance, and perform static analysis on the code at any time to track the progress. This is a concept of a rapid prototype. It is dangerous for a project to be unclear and invisible for a long time. Therefore, Google is willing to run the project first with the minimum time, then, the continuous iterative improvement is the same as the iterative delivery in Agile. As the iterative improvement process, the project and requirements will become clearer.

In Google, most projects share a code library, and any employee can download the code from other projects to other teams. This gives everyone a chance to learn efficiently. For example, if we encounter any program experience issues or compilation errors, we will go to Google search on the Internet. Google engineers generally can find the desired example in such a shared code library for reference. In addition, dare to share your code itself represents a responsible attitude towards code quality. You are welcome to come and give suggestions, it can also play a positive role in monitoring and promoting its own code. Google basically uses four programming languages: C ++, Java, Python, and Javascript. The worker's work machines are basically customized Linux systems, they will maintain these linux kernels and even the compilers included in them to ensure that all the code is compiled by the same version of the compiler and can run smoothly on any machine. When a project initiates an agreed interface, Google also has its own language called interface.
Protocols, through the description of this protocol file, set and SWE clearly understand the project requirements and functions, so you can start to write a test in parallel. Google has an interpreter that can translate protocol-format files into any of the four common languages. This saves the effort of human code duplication, it is also an example of tool culture.

In many other companies, testing and Development is responsible for automation. Google's point of view is that the automation of the stalls grows, and as the system changes, the demand changes, automation itself becomes increasingly vulnerable. Therefore, Google uses mock technology to isolate complex systems and implement lightweight automation for components that are more explicit and difficult to change. Engineers often run mock and automation on the entire system before checking in their own code, this effectively guarantees the code quality in the code library.

There are many interesting stories about Google's positioning of set from some of their recruitment cases. The set they most expect is to be able to propose a solution to the problem, regardless of whether the idea is optimal or not. For example, you can give a simple method and think about unit testing. Google doesn't think that a good set simply follows the unit test principle to do it step by step. Instead, it should try its best to raise its own doubts, for example, the scalability, reusability, security of multi-thread access, and whether the method can be optimized. What's more, we should consider pointer overflow, distributed calls, and how to analyze its robustness, whether the written unit tests are easy to understand. In addition to the unit tests, what else can be done to analyze risks such as code boundaries, deadlocks, and memory leaks. (It can be seen that set also requires a strong technical background)

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