The first chapter of Google software testing introduction

1. At Google, the software testing team is part of a central organizational unit called "Engineering productivity" (Engineering Productivity, engineering efficiency or engineering productivity) that spans the development, product launches, and various levels of testing for developing testers using tools , from unit-level testing to exploratory-level testing. Google has a large number of shared tools and testing infrastructures for Internet products, including search, advertising, Apps, YouTube videos and other products we offer on the Web.

2, Google is an innovation and speed-based company, quickly release useful code (if it fails, and only a few early users will be disappointed), iteratively increase the functionality that early users want to use (Maximize user feedback). In such an environment, testing has to become extraordinarily flexible, and in the skills to do a lot of pre-planning, just keep the simple maintenance does not really solve the problem. Sometimes, testing and development are intertwined to the point where they cannot differentiate each other, and at other times, testing and development are completely decoupled, and even developers do not know what the test is doing.

3. When someone asks me what is the key to Google's success, my first suggestion is not to recruit too many testers.

4, quality is not equal to testing, when you put the development process and test process together, like mixing in a mixer, know that can not distinguish between each other, you get the quality.

5, the test of the development process is an essential part of the development process and testing together when the marriage, is not only when the quality is reached.

6. Role

(1) Software Development Engineer (SWE): The job is to implement the function code that the end user uses. They create design documents, choose the optimal data structure and overall architecture, and spend a lot of time on code implementation and code review. Swe needs to write and test code, including test-driven design, unit testing, and participation in building tests of all sizes. SWE is responsible for the quality of the code they write, fix, and modify.

(2) Software Test development Engineer (SET): work center on Ke ' ce ' shi ' xing and general testing infrastructure. They participate in design reviews, and are very close to observing code quality and risk. To increase testability, they even refactor the code and write a unit test framework and an automated test framework. Set is an SWE partner in the code base, compared with an SWE to add functionality code or high performance code, set more focused on quality improvement and test coverage increase.

(3) test Engineer (TE): a role that is closely related to set, has its own different concerns-putting the user first to think, on behalf of the user's interests. Some Google Te will spend a lot of time simulating user scenarios and automating scripts or code writing. At the same time, they organize the tests that are written in Swe and set, analyze, interpret, test the results of the run, and drive test execution, especially in the final phase of the project, to promote product launches. Te is a true product expert, quality advisor, and risk analyst.

7. Organizational Structure

(1) Google's organizational reporting relationships are divided into different areas of focus (focus areas). These areas of focus include clients (Chrome, Google Toolbar, geography (Maps, Google Earth, etc.), advertising, Apps, Mobile, and more. All development engineers report to the managers, directors or vice presidents of these areas of focus.

(2) Testing is a stand-alone department, which is parallel to the field of focus (across various product areas of focus), which we call the engineering productivity team. The testers basically go to the product team on loan, to do things that improve quality, to find some places where the tests are inadequate, or to expose unacceptable defect rate data. Because testers do not report directly to the product team, we are not simply told that a project is in urgent need of release to pass the test. We have our own choice of priorities and will not compromise on issues such as reliability or security, unless something more important happens. The Engineering Productivity Team assigns testers based on the priority, complexity, and actual comparison of the different product teams.

8, climb, walk, run

(1) Google often includes only the most basic features available in the original version, and then gets feedback from internal and external users in the process of subsequent rapid iterations, with a high quality focus in each iteration. A product is generally experienced in the Canary version, development version, beta version, beta, or official release before it is released to the user.

(2) Canary version: This is the version that is built every day, used to exclude some obviously inappropriate versions of the filter. In general, only engineers (developers or testers) and managers of this product will be installed using the Canary version.

(3) Development version: This is the daily use of the developer version, usually released weekly. This version has some functionality and passes a series of tests. All developers under this product will be asked to install this version and actually use it in their daily work so that this version can be tested on a continuous basis. If a development version does not meet the needs of everyday real work, it will be called back to the Canary version.

(4) Beta version: Just a version that passed the continuous test. This version is basically the best version of the last one months and is the most stable and trusted version that engineers use in their daily lives. The beta version can be selected as an in-house version of the early adopters, and is a candidate version of the beta test if the version has consistently good performance.

(5) Beta or release: This version has evolved from a very stable beta version and has undergone a version of internal use and through all quality checks, and is the first release.

9. Test Type

(1) Small tests are generally automated and are used to verify that the code for a single function or stand-alone module works as expected, focusing on typical functional issues, data corruption, error conditions, and size difference errors (off-by-one errors are a common program design error). Small tests typically run for short periods of time, usually within a few seconds or less. Typically, small tests are implemented by an SWE, and a small number of set participation is involved, and TE is rarely involved in small tests. Small tests typically require the use of mock and fake (mock objects are simulations of the system since the outside, and at runtime can provide the desired result according to the hypothetical requirements, the fake object is a false implementation, the internal use of fixed data or logic, can only return specific results) to run. Te rarely writes small test code, but participates in running these tests to diagnose some specific errors. The main attempt to solve the small test is "does the code run as expected".

(2) Neutral testing is also usually automated. The test typically involves two or more interactions between two or more modules. The test is focused on verifying the interaction between these "functional neighbors" and whether the function is correct when invoking each other (our city features interactive area is the functional neighborhood). In the early stages of product development, when the standalone module function is developed, the set will drive the implementation and operation of these tests, and SWE will be deeply involved in coding, debugging, and maintaining these tests. If a medium test run fails, SWE will consciously look at the reason for the analysis. In the latter part of the development process, TE is either manually (if it is difficult to automate or is expensive to implement), or it is automated to execute these use cases. The problem that medium-sized testing is trying to solve is whether a series of neighboring modules interact with each other and work as we expect.

(3) Large-scale testing covers three or more than three (usually more) functional modules, using real user scenarios and actual user data, which can typically take several hours or longer to run. Large-scale testing focuses on the integration of all modules, but is more likely to result-driven, acceptance software to meet the needs of end users. All three of the engineer's roles are involved in large-scale testing, either through automated testing or exploratory testing. The problem that large-scale testing tries to solve is whether the product operates in the same way as the user expects and produces the expected results. This end-to-end usage scenario and operational behavior on top of the overall product or service is the focus of large-scale testing.

The first chapter of Google software testing introduction