Source: "Clean Code: The Professionalism of Programmers"
1. The goals of the developer
Developers should aim for "QA can't find any bugs".
(Although this goal is almost impossible to achieve, it is still the goal of our efforts. As the so-called "seek it, get it; seek it, get it; seek it, and you will lose.")
2. The role of QA in the project
The roles of QA in the team are the requirements specifier and the characterizer.
(In some projects, especially those with complex business needs and strong professional ability, there will be a full-time business researcher (BA). In these projects, the BA will be responsible for the business part of the above roles, and the QA will be responsible for the partial The part that tests the theory.)
3. Automated Testing Pyramid
| test category | test control | coverage | writer |
| unit test | XUnit | 100% | programmer |
| component testing | API | 50% | Business People & QA |
| Integration Testing | API | 20% | System Architect / Chief Designer |
| System test | GUI | 10% | System Architect & Technical Lead |
3.1 Unit testing
Unit tests are design documents that describe the lowest-level design details of a system. In TDD, the need to test first forces us to think about what constitutes good design. Unit tests should cover as much code as possible.
3.2 Component testing
Component testing is a type of acceptance testing. Written by business people and QA. This is achieved by calling the API. Mocking is required to decouple the component under test from other components. It is mainly a test written by business personnel for the normal path. There will also be some obvious corner cases, boundary states, and alternative paths. Most exception paths are covered by unit tests. There is no point in testing exception paths at the component testing layer.
3.3 Integration Testing
Only meaningful for larger systems with many components. It is also achieved by calling API, and also requires Mocking technology to achieve decoupling. Written by a system architect or lead designer. Integration testing is a choreography test, which mainly tests whether the components are assembled together for coordination, and does not test business rules . This layer can start to consider performance testing and throughput testing.
3.4 System Test
This is the final integration test. Contains performance tests and throughput tests. It is generally implemented through the operation of the GUI layer. Typically 10% of the code is covered. Written by system architects and technical leaders. The purpose of system testing is to ensure correct system construction, not system behavior (ie not business computing logic) . GUI testing is very expensive and should be minimized. It is better to decouple the GUI from the business rules, and replace the business rules with test stubs when testing the GUI.
3.5 Manual Exploratory Testing
The goal of human exploratory testing is to ensure that the system performs well under human manipulation, while creatively finding as many "wacky things" as possible. Coverage, business rules, and correctness of run paths are not goals. Generally, a QA person is responsible, or all project members participate in finding bugs within a specific time.
3.6 Unit Testing vs Acceptance Testing
Unit tests are written by programmers to programmers and are formal design documents.
The acceptance test business side writes the formal requirements document to the business side.
a. The test execution paths are different. Unit tests go deep inside the system, calling methods of specific classes. Acceptance tests are external to the system and operate through an API or GUI.
b. Fundamental difference: they are documentation first (design documentation vs requirements documentation) and testing is only a subsidiary function of them.
4. Summary
$ The quality of requirements and design is fundamental to ensuring that a software system is of good quality. Only by designing software that is easy to test can a project develop healthily.
$ Unit tests are the key in automated testing . It forces us to think about what constitutes good design. Software that is easy to test is designed consciously only with testing in mind.
$ In my experience, testing of the GUI layer must be left entirely to the system architect and technical lead. The cost of testing the GUI layer is too great. The system is designed to be easy to test only after those who have the power to decide the design of the system have been deeply tortured by GUI layer testing.
$ 同理，必须将系统的质量问题完全由开发人员负责，即这帮有权决定系统架构设计的人，才能使软件质量真正提高。将测试重担，甚至质量问题，推给测试人员是极度不专业的行为。软件的质量是设计出来的，不是测出来的。
各位业内人士，扪心自问：
作为项目组员之一的你，在做决定前是否对测试策略有清晰的认识？
自己的努力是否施展在正确的方向？
如果你是项目领导，你是否在团队中起到了应有的作用？你的技术储备足够吗？软件工程理论扎实吗？组织架构合理吗？每个组员的责、权、利统一吗？你有充分调动组员的积极性，挖掘他们的潜力吗？