How to develop a test strategy

A test strategy is a description of the relationship between a test project and a test task. It is used to describe what to test, how to measure, how to coordinate test resources and test time, and so on. The reasonable and efficient testing strategy will have a great impact on the progress of the test project. So, how to develop a good test strategy and to prevent the omission? What does a good test strategy contain? Below I give a usually used a template for your reference. I roughly divided the test strategy into a few modules: 1. Test scheduling, Release plan This module is used to list the important milestones of the test project itself, and each milestone requires a definite end time that can guide our subsequent testing. If the test schedule is insufficient, we can select the higher priority features in the subsequent test scope to perform the test, so as to maximize the quality of the product. 2. Test scope (prioritized) This section is divided into scope and out of scope. This section needs to explain which product modules are in the test scope and which are not considered in this phase of the test. For the modules in the test scope, the need to give priority to the appropriate test time is insufficient, for modules that are not in the scope of the test, you need to give reasons (why do not consider the test at this stage). 3. Testing resources testing resources in the test strategy is also a very important link, it is divided into human and tool two parts. Human resources mainly describe the people involved in the test, of course, can include a lot of roles, how professional testers, customers, product managers and so on. Tools mainly refer to the possibility of using other software (license may be required). 4. Test environment test environment mainly includes recommended environment solution, operating system requirements, hardware and software requirements.

• For the recommended solution, it is necessary to state the dependencies of the test project on other software, such as the test project pair. NET has dependencies, At this point we may be given the recommended version is probably 4.5.2, in the following test is mainly for 4.5.2 verification, and other versions of the simple verification, so in the product documentation to give 4.5.2 recommendations, mainly to illustrate that 4.5.2 is not a problem, other versions are not guaranteed.
• The operating system is primarily a description of the support for Windows or other operating system versions.

5. Test methods are listed primarily to illustrate what types of tests we will conduct for the test project, functional testing is mandatory, and non-functional testing is optional. (I believe that all children shoes to test methods have been recite, do not introduce each) 6. Use case design method use case design Everyone is also very clear, no longer introduced. 7. Document management for a complete product, the document is a very important link. It typically includes installation, upgrade documentation, user guides, and more. A document is not just a file, it needs to be fully tested before it can be published to customers. Poor documentation is likely to mislead users, leaving them losing confidence in the test project (although the customer seldom looks at the document ...). :)) 8. The risk management risk Management module needs to list the factors that are now known to be uncertain, which may come from technical, resource, or other factors. 9. Release package Validation This section has a certain particularity, and does not apply to all products. This section mainly validates the test project installation package to prevent changes in the process of producing the ISO file. Just write these, I hope you look at these 9 modules can find the first two questions of the answer to the article. We also welcome suggestions for improvement.

How to develop a test strategy