Introduction to Google software testing

Some time ago, I was confused , There is no clear learning direction and content . But one thing should be certain ： When you are confused, use your spare time to read ！

This book , At present, I just have a rough look at it , I feel a lot . Here are some personal notes , There are some differences with the original text . It is suggested that interested partners read the original books ！

 

One 、 Quality is not equal to testing

The mass is not measured ： It's impossible to develop quality software without testing .

Guarantee quality ：

　　 Test and development are carried out at the same time ：google The goal is .

　　 Development responsibility for quality ： Test immediately after writing a piece of code , More code done, more testing done ; Quality is like preventive behavior （ Quality is a problem in the development process , It's not a test problem ）.

       Test ： Online bug Heavy , It will roll back the version ; Judge how well prevention is being done （ Development testing , Can you ensure that there will be no rollback level bug It happened ）.

 

Two 、 role

1、 Software development engineers SWE：

Implement functional code used by end users ：

　　 Create design documents 、 Choose the best data structure and overall architecture 、 Code and implementation auditing .

Write test code ：

　　 Test Driven Design 、 Unit test 、 Participate in building tests of all sizes .

Add functional code or code that improves performance .

Quality responsibility ：

　　 Write to them 、 Repaired and modified code is responsible for quality （ Fault tolerant design 、 Fault recovery 、 Test Driven Design 、 Unit test ）.

2、 Software Test Development Engineer SET：

Focus of work ：

　　 Guarantee SWE The developed functional modules have testability ： Participate in design review , Observe code quality and risk ; Code may be refactored , Write unit test framework and automated test framework .

　　 Common test infrastructure .

Responsible for providing test support ：

       There's a testing framework ： You can isolate newly developed code , Manage code submission by simulating a real work environment and code submission queue .

Concern ： Quality improvement and increased test coverage .

The purpose of writing code is ： Can make SWE Test your own function .

3、 Test Engineer TE

Focus on testing from the user's point of view ：

       Spend a lot of time simulating user scenarios and automating script or code writing .

       Whether the performance expectations are met , In security 、 Internationalization 、 Whether the access permission meets the requirements of users .

Work ：

　　 Organize overall quality practices （ hold SWE and SET The written tests are organized into categories ）, Analyze and interpret test execution results , Drive test execution , Build end to end automated testing .

 

3、 ... and 、 Organizational structure

Most companies ：

       Senior managers usually come from product managers or development managers , Not from the test team .

       When the product is released , The priority is whether the function is complete and easy to use , Little consideration is given to quality .

       As a team , Testing is always making way for development ：“ The industry is full of flaws 、 Products of premature birth ” The problem is ; If the quality is not good, release another patch .

Google Organize reporting relationships ：

       Divide different areas of focus ： Client 、 Geography 、 Advertising, etc （ The development work is reported to these domain focused managers ）.

       Testing is an independent department ： Engineering productivity team

• Enter the product team on lease ：

1)      Do related work to improve quality , Or publish some unacceptable defect rate data ;

2)      Not reporting directly to the product team , You can't pass the test just because the project needs to be released urgently （ You can negotiate in advance . Have your own priorities , In reliability 、 Security issues don't compromise ）;

3)      Can make SET and TE Keep fresh and busy , A good idea can spread quickly within the company

• According to the priorities of different product teams 、 Complexity , And compared with other products , And then assign testers ( There may be a mistake , But on the whole, it will maintain a certain balance between the actual demand and the unclear demand ).

 

    Four 、 Climb, walk and run

1、Google Products often contain only the most basic features available in the initial release

Feedback from internal and external users is obtained in the subsequent fast iterations .

Every iteration pays a lot of attention to quality .

Before the product is released , Will experience the Canary 、 Develop 、 Test 、beta Or officially release the version .

2、 The Canary version

The version to build every day （ Members of the core development team will install ）：

       This version may not be able to use the basic functions it should have ;

       Error code installed , Mobile phones don't even have access to basic features ;

Used to exclude filtering obviously inappropriate versions ：

       Build failed , It means that there may be serious problems with the process

3、 Development version

Release... Every week , This version has certain functions and passed a series of tests ： Product engineers will install .

Can't meet the daily needs of real work , Will call back the Canary version ： The engineering team will take the time to reassess .

4、 Test version

Passed the continuous test , The best version in a month .

Has sustained good performance , Will act as beta Candidates for testing .

5、beta Or release the version

The first version released to the public ： Experienced internal use and passed all quality assessments .

 

5、 ... and 、 Test type

Use appellation ： Small tests 、 Medium test 、 Big test .

Emphasize the scope of the test, not the form ; The smaller the scale , The more likely it is to be automated testing .

1、 Small tests

Verify that the code for a single function or function module works as expected .

It's usually automated ：

       It can be done in seconds or less .

       SWE Realize , There will also be a small amount of SET Participate in .

Use mock, stay fake（ False realization ） Execute... In the environment .

2、 Medium test

Verify the interaction between function modules and the correct function when calling each other .

It's usually automated ：

       After the development of independent modules ,SET Will drive the implementation and execution of these tests ,SWE Will be deeply involved in , Code together 、 Debug and maintain these tests .

       Execution failed ,SWE Will consciously examine and analyze the reasons .

       Late development ,TE These use cases will be executed manually or automatically .

General execution in the false implementation of （fake） In the environment or in the real world .

3、 Big test

Covering multiple modules , Focus on the integration of all modules , Tends to result driven , Verify that the software meets the needs of end users .

Or through automation , Or exploratory testing ： All three kinds of engineers are involved in ; It takes hours or more .

It's usually executed in a real environment , And use real user data and