"How Google Test Software" reading experience

How Google test software software test development engineer

This is one of the programs of the course Software testing: Project #1: Reading a book, from Group: Developer is tester

Member: Wu Jia Rongjingtao Chen Shaopeng Guo Luwen Liang He Jin Yue

Show ppt:http://slides.com/wujiarong/deck-1#/

Part 1:summary of content

The whole book is divided into three parts, five chapters

Part I: A brief introduction to Google software testing concepts, roles, organizational structures, processes, and test types. Chapter One: Introduction to Google software testing

1. At Google, the software testing team is a central organizational unit of "Engineering productivity," and its testing approach is likely to be a copycat example for other companies. Testing and development are sometimes intertwined and sometimes completely separated, and this Google has a very small number of full-time testers who are not just the testers ' problem, but the developers themselves are the testers. Stop development and test isolation, quality is not equal to testing.
2. Roles, Google combines the development process with testing and creates these roles, including: Software Development Engineer (SWE), Software Test development Engineer (SET), test Engineer (TE), and a brief introduction to these roles.
3. Organizations, in Google, testing is an independent department that joins the product team on loan.
4. Crawl and run, Google's original version only includes the most basic use features, and then constantly collect user feedback iterative upgrade way to improve product quality. is divided into the Canary version (the most basic, to screen out the obviously inappropriate features of the version), the development version (the developer's daily use of the version), the test version (through the continuous testing version, can be used as an internal early adopters) and beta or release version (the first release of the release), Provides us with a good opportunity to test and verify.
5. Test types, divided into: small test (can be automated), medium-sized test (automated implementation, will involve inter-module interaction) and large-scale testing (involving more modules, using real user scenarios and real user data).

Part Two: Introducing the roles involved in software testing and their main roles. Chapter II: Software Test Development Engineer (SET)

1. Software Test development Engineer related work content, in unit testing to give developers support, provide developers with testing framework. This paper introduces the work task of set and the process of testing work, explains that set is the engineer's role first, and is a software engineer, the test is another function of application product, set is the owner of this function; early in the project, Google will not let the test intervene prematurely; team structure, design documentation, The set also simplifies the work of the relevant project members while advancing the project; interfaces and protocols, in order to run integration tests as early as possible, set provides mock and fake, automated planning, testability, Google takes code reviews as the center of the development process, and set becomes one of the source's owners And a real example of the process of software testing is presented through an instance, and the definition of test size, including small, medium and large scale tests, describes the use of different sizes of software testing on shared test platforms and their advantages and disadvantages.
2. Describes the "test certification" approach used in the implementation of testing – by completing test tasks to obtain a "certified" logo that motivates developers to participate in the testing process, and interviews with test-certified founders.
3. For some description of set recruitment, the interview is focused on how candidates think about the solution to the problem, and a good set will naturally consider the test code.
4. Finally, we recorded an interview with the creator of tool development engineer Ted Maori and web driver Simon Stewart, who facilitated the development of excellent test frameworks and testing tools.

Chapter III: Test Engineer (TE)

1. The focus of the test engineer (TE) is to assess the impact of the product on the user and the risk of the overall software PRODUCT objectives. Te not only has the ability to develop software technology, but more importantly, TE also has the ability to check the quality of the software with the user as the center and to have some constraints on the developers.
2. A test engineer is a user-oriented test role, where Te first discovers the most risky areas of software in some of the most appropriate ways and tries to reduce or eliminate them.
3. The work of the test engineer, the early stages of research and development, TE's work is not much, TE enters the product, SWE and set have done a lot of work in testing technology and quality, can be the starting point of Te, Te will be involved in various stages of the project, TE is usually the most famous person in the team, Requires keen insight and leadership. In general, TE's responsibilities include test planning and risk analysis, review requirements, design, code and testing, exploratory testing, user scenarios, writing/executing test cases, and using statistical/user feedback, and Te's main job is to expose the risk. If you can't test it all, it's a principle.
   Test plans are among the first to be forgotten test products, ACC (Attribute Component Capability, traits, components, competencies) is an alternative to the test plan. Risks include risk analysis and risk mitigation 10-minute test plan (the 10-minute test plan by James Whittaker) and crowdsourcing (crowd-sourcing); The lifecycle of test cases and bugs, and Google's management of bugs is unique , the database of bugs is completely open, by comparing the life of the bug to the child, introducing TE's recruiting and Google test leadership and management, and introducing the test of maintenance mode through the Google Desktop Case study also introduced the quality Robot experiment and bite experiment, as well as the Google Test Analytic and 0 cost testing processes as well as external vendors.
4. Included with Google Docs test engineer Lindsay Webster and the YouTube test engineer, Apple Chow chat records.

Fourth: Test engineering Manager (TEM)

1. To test the engineering manager's work, TEM is responsible for liaising with all support teams, connecting TE and set, possessing technical capabilities, leadership and coordination capabilities, and is the strongest product specialist in the relevant project. TEM needs to understand its products and know how to use them to optimize project engineering.
2. Get projects and people, manage the flow of resource allocation, and get new projects.
3. Influence, Test engineering manager to make the team influential, to help engineers to play their own corresponding influence, to deal with cross-team communication;
4. Gmail's testing experience and the. Android Test experience and the interview with Chrome's Test manager tell us about the importance of the Test engineering manager, the shortcuts in development testing, and the power of development testing. Also included are interviews with the head of the search for geographic information, director of engineering tools, and Google test director and engineering manager in India.

Part III: A brief introduction to Google's testing flaws and the direction of improvement fifth: Google Software testing improvements

1. The deadly flaw in Google's process has been tested as a crutch for development and testing of the organizational structure separating testers to worship the test product better than the software itself. The most profound fatal flaw is that after the most rigorous testing is released, the user will inevitably find a problem with the test missing.
2. Set this role will eventually become a role with the Software Development engineer, the role of TE has been a more comprehensive and low-cost alternative, the corresponding number of test directors and managers will be greatly reduced.
3. The future of Google's testing infrastructure will be more economical to test with a more open, cloud-based approach.
4. The engineering managers and directors of the centralized testing department are scattered over the more focused project teams and responsibilities, less on the testing process, more on the product itself, and the familiar and favorite test methods are about to end.

Appendix

Describes the chrome OS test plan and Chrome's roaming test as well as the related tools and Code blog post and Glossary.

Part 2:educational value of material

For us, the three characters presented in this book are the most impressive.
They are: Software Development Engineer (Swe,software Engineer), Software Test development engineer (Set,software Engineer in test) and test engineer (Te,test Engineer).
Before we learned to test and read how Google test software, there was only one engineer for us in the software industry, and that was the development engineer.
The idea is naïve and ignorant, but we do have this idea.

From the organization of this book, the main line of the book is to introduce several different roles: Software test development engineer, test engineer, Test engineering manager.

To determine what our team is going to write about in this section. Let's take a look at those roles that are responsible for the content.

Software Development Engineer (SWE)
"Hgts": Software development Engineers are a traditional development role, and their studios implement the functional code that end users use.

Software Test Development Engineer (SET)
"Hgts": Software test development engineer, is also a development role, just focus on the testability and common test infrastructure framework.

Test Engineer (TE)
"Hgts": Test Engineer is a close relationship with the set of roles, have their own different points of concern-put the user in the first to think, on behalf of the interests of users.

Test Engineering Manager (Tem,test Engineering manager)
"Hgts": Test engineers and Test development engineers are dedicated to supporting users and development engineers respectively. There is another role that can link the two: The Test engineering Manager (TEM). The Test engineering manager is a technical post as an independent contributor and is responsible for the communication between all support teams (development, product management, product launches, documentation, etc.).

The introduction of these roles, if the rough summary of what the book said, I can say, the above content.
Again, the organization of this book is how these different roles play a role in Google's code production.

Things or people that span multiple roles are the biggest attraction for us, and it's easy to confuse people.
Like the unfamiliar role of the book: SET, Software Test development engineer.

In order to make this part of the content of the depth of the value, rather than the breadth of the generalities, we are going around the "hgts" in detail about the role of software test development engineer.

Google's development release model
Before I know how Google does it, I think I need to know how Google is developing it.

"Hgts" Introduction, Google has a "crawl, walk, run" development release mode.

In other words, Google will never again release a lot of features in the product, in essence, after the implementation of a basic core functionality of a product, it will be released to use immediately, and then from the user where to get real feedback, and then iterative development.

In essence, this model can accelerate the iterative development process, and for the development of new features, quickly get user feedback, if the user's welcome, based on user feedback to improve, if the user feel more function, can immediately discard, and stop the direction or the development of the branch. This in essence can make Google's development efficiency greatly improved.

Google's development model, which forms a version of the various development processes in Google style.

Canary version: This is the version that is built every day, to eliminate the need to filter out some obviously inappropriate versions.
Development version: This is a daily version of the developer, usually released weekly.
Beta version: This is the version and the Order test.
Beta or Release: This version evolved from a very stable beta version, experienced internal use and passed a version of all quality checks, and was the first release.

There is no doubt that software development engineers (SWE) play a role as a function developer during the build and development of the above versions. This is a very important role, because the user needs of the function, they have to be implemented.

So, what is the task of the Software test development engineer? Why do they have the same status as software development engineers? Why is recruiting set more difficult than hiring an SWE?

Software Test Development Engineer (SET)

Set description

First to quote "Hgts" a description of the set of words.

"Set first is the role of the engineer, who makes the test live in all of the previously discussed Google development processes." Set is house arrest, test development engineer. The most important point is that set is a software engineer, as we advertised in the poster and in the internal promotion system, is a 100% coding role. “
"Another feature of the product is applied when testing, and set is the owner of the feature. ”

Since the test page is categorized as a functional feature of the application product, there is no doubt that in a nutshell set is, understand the development of the test engineer, set developed a test product, is closely related to the product itself, the testing of functional products.

Early stages of the project

There is a cultural atmosphere inside Google: Companies encourage internal employees to use their 20% of their working time to do creative work.
In essence, many of Google's products originate from the work of 20% of employees, many of which are proven to be valuable and then transformed by amateur products into the company's business-oriented products.

But is there a need to ensure the quality of the product in the process of change?

"At this stage, the function is far more important than quality," says Hgts.

"A product that cares about quality when it's conceptually not fully deterministic, is a symptom of a priority disorder." Many of the prototypes from the google20% effort have undergone re-engineering when they are released in later Dogfood or beta releases, with almost zero probability of the original code being retained. Obviously, it's a stupid thing to stress testing in the early stages of the experiment. ”

This idea is important because it is a waste of resources to devote a lot of attention to quality issues before it is clear that such products are valuable.

From a subjective point of view, it is difficult to attract the attention of set before the product is proven to be valuable.

Automation planning

There are a lot of things that set needs to be done, and the plan to automate the testing of the project is their goal.

One principle is that automation plans must be reasonable and influential.

To achieve automated testing, set follows the following principles:

First of all, the error-prone interface is built into a mock and fake (mock dereliction of duty on the outside of the system of simulation, at runtime can provide the desired results according to the hypothetical needs; The fake object is a false implementation that uses fixed data or logic internally and only returns specific results)

Second, build a lightweight automation framework that controls the creation and execution of mock systems.

Testability

Testability is a task that ties the SWE and the set together.

This is a simple way to understand the contribution of SWE and set to the testability of a project. The goal of set is that for every modification of the project product, every commit to the code, every effort and attempt of the SWE can quickly check the changes, build, verify whether there is a problem with the change, and whether the code has a bug. Then, in a most efficient way, the corresponding feedback information is sent to the code's changing person.

Definition of test size

For testing convenience, Google defines a set of test naming rules itself.
Small test: Verifies the functionality of a code unit, usually a unit test.
Medium-sized test: Verifies the interaction between two or more module applications.
Large-scale testing: Verify how the system works as a whole.

Application of test size definition

Recruitment of test Engineers

Word: It is necessary to develop, but also to understand the test.

Read the biggest harvest

Do every thing, should have a certain purpose, otherwise, there is no sense of direction. Every experience should be able to perceive what the experience brings to itself.

The reading of this book, we think, brought us two points very deep experience and harvest.

One, the commit queue and continuous integration

Recently participated in a project. Plays a role as a Web architect and technology leader.

We use Gitlab as a remote repository, use Git for versioning, and use Git's branches for collaborative development.

Shortly after the project began, the Web Services Section we have not had a strong sense of testing, are functional-oriented development to complete a specific function for the development of phased standards.

The way we control the quality of the code and the integrity of each commit is by direct manual inspection.

It should be said that such a development process is relatively primitive. Automated builds and automated testing are not implemented. Does not take full advantage of Gitlab's automated build and continuous integration capabilities.

Perhaps the impact of this reading is to give our team a tendency and awareness to achieve such a build and integration.

Secondly, web automation testing

As a web front-end development engineer, I haven't tried the front-end test before. According to the previous development experience, the Web front end seems to be unable to conduct automated testing. Because it's basically a UI operation, it's hard to determine input and output. can only be human-computer interaction, manually determine the correctness of logic and process correctness.

Until I read an interview with the founder of the Webdriver project in this book. Just know that the original web front-end automation testing is not impossible, but has been a concrete attempt and implementation!

This recognition is a huge surprise to me.

I will try to learn webdriver and try to apply Web Automation testing to specific projects.

Part 3:recommendation

Google software testing is a very valuable book, so I think it's worth recommending this book to everyone. For a long time, the development of the theory and practice of software testing has been in the relative shortage of resources and manpower, the boundary of work content is also very vague state. The problem with other books about software testing is that the location of the station is either too high or too low. Written in an academic tone, the engineer feels that it has nothing to do with his or her own practical work experience, but does not form an effective theorist; the generalities are written by considerable imagination, but there are no instances and no tools-word, light says a bunch of tests. , but did not see what good products were measured, nor did they develop tools, theories and culture in the process.

The difference between Google software testing is that the software products that the IT giant has produced are including women. So, the production process of these products as a model in the software development life cycle, should be not only more correct, but also a more communication base, and therefore more valuable. Software testing is one of the most touchpoints in the software development life cycle, and through this book, you can see how these it giants are doing-how they design the supporting corporate structure, how to handle the relationship between software testing and other life cycle links, how to implement engineering practices based on ideas, What kind of supporting environment and engineering tools have been developed ... This series of questions, read the answers given by Microsoft and Google, let the reader know what the ideal, or high-level software test has achieved under current software and hardware conditions, so that when planning their own software testing-related team configuration and engineering practices, Has a very important reference.

After reading the "Google software Test" and let me see something new, this is mainly the software delivery model from the boxed into the online brought, so the time characteristics from discrete to continuous, spatial characteristics from a single to multi-dimensional, software testing in order to adapt to these changes, the concept must be more flexible on the one hand, On the other hand, it has to be more simple and effective in execution. These two conflicting requirements, the management of software testing and implementation personnel have put forward a great challenge. Not surprisingly, I've seen this book on a basic level with the same testing goals as traditional boxed software testing: High availability, high performance, optimized user experience, but the conceptual and technical changes have taken place, and I sincerely ask readers to focus on the book's discussion of the scale of the test, And the design idea of performance testing tools, the information is very large. In addition, careful study of the appendix of the two test plans, there will be no small gains.

Finally, we sincerely recommend the "Google Software Testing", which will definitely make you benefit.

"How Google Test Software" reading experience