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 ： Write a piece of code and test it immediately , 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 ： on-line 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 happen ）.
Two 、 role
1、 Software Development Engineer SWE：
Implement the function code used by the end user ：
Create design documents 、 Choose the best data structure and overall architecture 、 Code implementation and code auditing .
Write test code ：
Test Driven Design 、 unit testing 、 Participate in building tests of all sizes .
Add functional code or improve performance code .
Quality responsibility ：
Write to them 、 The repaired and modified code is responsible for quality （ Fault tolerant design 、 Fault recovery 、 Test Driven Design 、 unit testing ）.
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 ; It's possible to refactor the code , 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 , By simulating the real working environment and code submission queue to manage the code submission .
Focus on ： Quality improvement and increased test coverage .
The purpose of writing code is ： It 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 rights meet the requirements of users .
Organize overall quality practices （ hold SWE and SET The written tests are organized into categories ）, Analyze and interpret test run 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 disclose 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) It can make SET and TE Keep fresh and busy , A good idea can spread quickly within the company
- According to the priority 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 product launch , Will experience the Canary 、 Development 、 test 、beta Or the official release .
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
Weekly release , 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 the last month .
Has sustained good performance , Will act as beta Candidates for testing .
5、beta Or release 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 run in seconds or less .
SWE Realization , There will also be a small amount of SET Participate in .
Use mock, stay fake（ False realization ） Running in the environment .
2、 Medium test
Verify that the function modules interact and call each other correctly .
It's usually automated ：
After the development of independent modules ,SET Will drive the implementation and running of these tests ,SWE Will be deeply involved in , Code together 、 Debug and maintain these tests .
Run failed ,SWE Will consciously check and analyze the reasons .
Late development ,TE These use cases will be executed manually or automatically .
Generally run in a fake implementation （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 the end user .
Or through automation , Or exploratory testing ： All three kinds of engineers are involved in ; It takes hours or more .
It usually runs in a real environment , And use real user data and resources