Analysis of software testing scheme

What role does the test solution play in the software testing process? How do I compile a test plan? There are often no consistent answers to similar questions about software testing solutions. Different companies often have their own test solution templates, and the understanding of test engineers is also different. The following is my understanding of the test solution and I hope it will be helpful.

What is the purpose of writing a test plan?Some people may say: according to the product functional requirements (such as PRD) documentation, refer to the product design documentation, the test engineer can understand the requirements, design test cases, and do not need the test solution documentation, even if you write a test plan, you just need to copy the product requirements and design documents. The reason for having these ideas is that they do not really understand the role of the test solution. In fact, the function of the software testing solution is very similar to the product design instructions (documentation). The development engineers code the product to implement the function according to the product functional requirements and design instructions, test engineers must design and execute test cases based on product functional requirements and test plans, and also refer to the product design instructions. Therefore, the purpose of the test plan is: determine what to test, how to test, and what quality standards to meet.

How to generate effective test solutions?If you just copy the product requirements and some design instructions and give a test progress plan, such a test plan is of little significance to the case design and execution. As a solution, I want to include at least a few key factors: scope, time, resources and quality, and products in different industries, the test plan should decompose and adjust these key factors accordingly. For software testing solutions, I think it should mainly include: test requirement analysis, test strategy, test resources, test plans, Project risks and quality. If we can clarify the above factors, such a test scheme can effectively guide our test design and implementation.

Test Requirement Analysis:Test Requirement analysis refers to converting product requirements (such as PRD documents) and user understanding (User Experience) into test function points. Product requirements are the main input of our test requirements, but not all, we also need to carefully analyze the product design instructions to generate more testable functional points (these features are often not included in the product requirements ). You must also analyze performance, security, interfaces, and regression testing ranges. Test requirements are the main basis for determining the test schedule and resources.

Test policy:After the test requirements are determined, we need to think about how to verify the functional points in the test requirements and what testing methods are used: manual, automated testing, and whether new methods or tools are required, such as manual testing for new features, some regression cases use automated scripts, use new methods to prepare test data, and use appropriate tools to verify complex test results. Determine the test priority, and determine which business functions are the most important. That is, the new Code module, which old modules are greatly changed, and the related functional points should be tested. The test cannot cover 100%, however, important and high-risk functions must be fully verified to ensure that resources are invested in the tasks with the highest priority.

Test Resource:Generally, a team has multiple projects at the same time. The testing PM needs to determine the testing resources for each project based on the project priority. Generally, the software testing resources mainly include: manpower and equipment machines.

Test Plan:Evaluate the test progress plan based on the test requirements and policies and the Project Priority and test resources. Generally, the more adequate the test resources are, the more optimistic the test progress is, but not absolute, sometimes some software bugs will block the Test Progress, which is also part of the project risk.

Risk Management: Before the test execution starts, it is important to analyze and identify possible risks. Prevention and countermeasures can be taken in advance. Therefore, during the project process, we need to regularly assess the Test Progress, early risk warning.

Quality:Quality refers to the standards to be met by testing projects. Each company and project has corresponding standards and requirements. As quality standards can be the consensus of most projects within the company, therefore, you do not need to list them in the test plan. For test projects, it is common to set quality standards based on the test case execution rate, pass rate, and bug levels/quantity not closed.

After the first draft of the test scheme is completed, project-related testing, development, and demand side colleagues must be invited to review the requirements and design, and the testing methods should be discussed, we can improve product requirements, provide more input for product design details, so that developers can improve code logic in advance, and test engineers can further understand requirements and design, this helps design and improve the test case design to ensure test coverage.