Test Plan Evaluation Model

Test Plan Evaluation ModelChen nengji-8-12 original article: Test Plan Evaluation Model-James Bach, to answer "is the test plan determined ?" To answer this question, we need to answer the test plan. Although there are many test plan document templates, they do not distinguish between good plans and bad plans. This model identifies basic concepts and functions that the test plan should have, the criteria that the test plan should meet, and provides some inspiration to help determine whether the function of the test plan meets the criteria. Terms and concepts _ Test Plan. A test plan is a collection of ideas that guide and reflect the testing process of the plan._ Test Plan document. The test plan document is any document used to pass the test plan information. However, the test plan document is not the only source of the test plan information. The test plan information also includes oral and traditional corporate practices._ Test Strategy. The test strategy is the design and execution method of the test and is used to support effective quality assessment. The test policy is used to plan which parts of the product require test coverage and what testing methods and skills are required._ Test Project. A test project is a project that tests the application of a policy and outputs results.Test Plan Functions Test Plan features 1. Support development quality assessment to ensure informed and timely decisions on products. 2. Describe and demonstrate the testing strategy based on technical requirements and technical risks (including proposed testing coverage ). Alert about the benefits and limitations of the test policy. 3. To allow the test project to proceed smoothly, describe and indicate any specific requirements or access criteria to be met, as well as exit criteria or determine the process of stopping the test. 4. Supports initialization and organization of test projects, including preparation, team formation, assignment of duties, acquisition of tools, task plans and timelines. 5. Supports daily management and evaluation of test projects and test policies. 6. Support for effective coordination and cooperation, between test team members, and between test team and other team members. 7. identify and manage risks or problems that may affect the project. 8. Specify the results and processes to be output for the test project. 9. Record historical information to support Process auditing, process improvement, and future testing projects. Test Plan quality criteria test plan quality standards _ Usefulness. Effectiveness: Can the test plan effectively support its functions?_ Accuracy. Accuracy. Is it consistent with the actual status?_ Efficiency. Efficiency: Do you want to make full use of existing resources?_ Adaptability. Adaptability: is it compatible with reasonable changes in the project and some unexpected changes?_ Clarity. Clarity: is the test plan self-contradictory? Is it clear enough?_ Usability. Availability: is the test plan document simple, maintainable, and well organized?_ Compliance. Consistency: is it consistent with external requirements?_ Foundation. Is it the result of the effective test plan process?_ Feasibility. Feasibility: Is the organization capable of executing the test plan?Test Plan heuristics test plan

Inspiration	Basic inspiration
1. the test should be optimized to locate the problem faster, instead of trying to locate all the problems with the same priority.	The sooner the problem is discovered, the higher the risk of securely fixing the problem before the ship date.
2. The testing strategy should focus on potential technical risks, and also on low-risk areas to prevent the risk analysis of errors.	It is impossible to perform a full test.
3. The test policy should specify the platform configuration, how the product operates, how the product is observed, and how the product is evaluated.	Ignoring these aspects may cause some important problems not to be discovered.
4. The testing strategy should be changed according to the testing technology and method. The methods covered by the evaluation test should consider the multidimensional coverage, including the structure, functions, Data, platform, operation method and requirements.	No test method can discover all important problems, and we are never sure we have found all problems. The diversity of test strategies can reduce the risk that a single test method only discovers specific types of problems.
5. The test policy should specify how the test data is designed and generated.	Testing policies are usually organized around functions and code so that testers can consider connecting to data during testing. This usually means that the test policy focuses too much on functional verification, while ignoring reliability.
6. Not all tests need to be specified in detail in advance. The testing strategy should allow the tester to fully consider the environmental factors for reasoning, focusing on important but unexpected issues.	Encourage reasonable test changes without offending basic coverage, such as interaction with which results, exploratory testing, and occasional test coverage.
7. Test the implied requirements-what is included in the requirements, not just what is said by the requirements	However, testing based on written requirements does not expose important issues, because the requirements are generally not completely defined and natural language is often misunderstood.
8. The tester should try to communicate with developers, technical support personnel and technical document writing personnel as much as possible, and should also have more contact with real users and customers to better understand the needs	Other team members or stakeholders often have a lot of useful information for testing regarding product issues or potential problems.
9. The tester should consult more developers to help them build more testability products.	The effectiveness of the test strategy depends on the testability of the product.
10. the test plan should emphasize unconventional and project-specific test strategies and test items.	Do not make the test plan look like a test template
11. The testing project should use manual testing where the manual testing is done well, and use automated testing where the automated testing is done well. Manual testing should be applied in the areas that need to be considered, automated testing should be applied in areas that require high repetition, where fast execution is required, and where adjustments are not made.	Manual testing and automated testing are two completely different testing methods.
12. The test schedule should reflect the dependency with the development progress, the product testability, the time required to report the problem, and the risk assessment.	Testing is not an independent activity.
13. The test progress should be kept as independent and decisive as possible. This can only be done through testing and development in parallel, and the tester finds errors as quickly as possible than the developer fixes	This is very important for the cropping test process to reduce stress.
14. The feedback cycle between the tester and the developer should be as close as possible. The test process should be designed to provide a rapid feedback mechanism for developers to provide feedback on recent new features and changes. The tester should obtain this information before a complete regression test starts.	This is very important for maximizing the speed and efficiency of quality improvement.
15. The test project should obtain quality information to help evaluate and adjust the test project, not only through formal test channels, but also through informal tests outside the review, beta testing, and test group	Prevent blind spots that cannot be found by the test strategy used for formal testing
16. documents related to test strategies, including test cases and test methods should pass Review	Expose blind spots in the test design through review, and learn from each other and improve