Benefits of a test plan
- Know the exact scope of the test, what is the test strategy
- Estimate the specific workload and test resources, and everyone has a clear division of labor, so it is not easy to repeat the test
- The test progress is controllable and the test completion status is known in real time
- Potential risks can be identified in advance and we need to respond when requirements change
The test plan
Test range
Contains: the object under test, the main test content
The determination of test scope is generally carried out after the completion of test requirement analysis, so the process of determination of test scope is also a further examination of test requirement analysis to some extent, which helps to find potential test omissions in the early stage.
Due to the limited time and cost of testing, targeted testing must be carried out, so the scope of testing should be clear about what to test and what not to test.
The test strategy
The testing strategy is to make clear what to test first and what to test after and how to test, make clear the test focus, and the sequence of each test;
For example, for the user login module, the two potential problems of “user cannot log in normally” and “user cannot reset password” are not of high importance. Therefore, the “user can log in normally” should be tested according to the priority.
The test strategy also explains what type of test and method to use, not only why the test type was chosen, but also how to implement it in detail.
Number one: functional testing
- For functional testing, test cases should be designed according to the mind map of test requirements analysis
- Also, assess the testability of the software under test, and if there are testability issues, consider practical workarounds ahead of time, requiring developers to provide testability interfaces
Second: compatibility testing
- For the Web test, determine the browser type and version to be covered. For the mobile device test, determine the device type and iOS/Android version to be covered
- The implementation of compatibility test is usually in the later stage of functional test, that is to say, the compatibility test will start only when the functions are basically stable
- When a new front-end framework or component library is introduced to the front-end, compatibility evaluation is usually conducted in the early stage to ensure that compatibility problems that cannot be solved in the later stage will not be introduced
Third: performance testing
In the early stage, the performance requirements (number of concurrent users, response time, transaction throughput) were defined, and the performance test scenarios were designed and the performance test framework was determined based on the characteristics of the system under test
Such as:
- Whether stress testing is initiated directly at the API level, or whether protocol-based stress testing must simulate end-user behavior;
- Whether to perform pressure tests based on modules or initiate full-link pressure tests
If performance is a background data sensitive scenario, you also need to determine the magnitude and distribution of the background data, and determine the technical solution for generating the background data, such as whether to generate the test data through concurrent API calls, do bulk INSERT and update operations directly on the database, or a combination of the two.
Finally, either way, it is important to know the number of single-user scripts to be developed so that the pressure test scenarios can be assembled smoothly down the road.
As for the implementation of performance testing, first of all, you need to determine the type of performance testing according to the problem you want to solve, and then carry out the testing according to the specific type of performance testing.
Performance test implementation related
- The implementation of performance testing often depends on the business scenario to determine which single-user scripts need to be developed. The development of scripts involves many concepts unique to performance testing scripts, such as thinking time, collection points, dynamic association, and so on.
- Script development is completed, you need to the script for the unit organization test Scenario (Scenario), Scenario definition is simply doing what percentage of the user login, what percentage of the user to do inquiry, each user need to wait for how much time between steps, a concurrent user growth is 5 seconds, or 5 second 2, etc.
- Finally, the concrete test scenario is executed. Unlike automated functional tests, the interpretation of performance test reports after the execution of performance tests is the most critical point in the whole testing process.
There are many more types of tests
For example: interface testing, integration testing, security testing, capacity verification, installation testing, failure recovery testing
Test resources
Includes: testers and test environments
Testing resources need to be clear about who is testing and where
Testing progress
Main description: the start time of various tests, the amount of work required, the estimated completion time, and based on this to suggest the final product launch time
In the traditional waterfall model: The test schedule is entirely dependent on the time it takes to complete development and deliver the test version. If there is a delay in the development and delivery of a test release, the overall time to launch of the product will also be delayed without tailoring the test requirements.
In agile mode, however, testing activities are carried out throughout the Development process, and much of the testing and Development work is carried out simultaneously, such as in a behavior-Driven Development mode, so that the testing schedule is not entirely dependent on the time the Development takes to deliver a testable version.
Behavior-driven development: BDD refers to the ability to write test cases in natural language that are not readable by programmers
Test risk estimates
For requirements change, such as requirements increase, delete, modify, be sure to re-test requirements analysis, determine the changed test scope and resource assessment, and timely communicate with the project manager and product manager about the test schedule changes caused by this
During the test, the following situations may occur
- Inaccurate test workload assessment
- Additional test types need to be added
- Fix some serious bugs that require full regression
- Send test delay
- Personnel changes
Therefore, in the development of the test plan, it is necessary to estimate the potential risks that may exist in the whole test process, and the response strategy when the risk occurs.