How to develop a test strategy

If you are the head of a test project and give you a test project, how do you develop a test strategy?

I only stand in personal position, very superficial to say their own views, I will be through the following four aspects of strategy analysis and development:

1. Determine test target and test scope

To figure out what you're testing? What is measured here refers to the scope of the test, the focus and the test target.

First of all, the test range, is not the need for shoes what we test what? No, as a test leader, the scope of testing here requires a higher level and more perspective. A higher level means that in addition to the final product functional quality needs to be tested, the process documentation, and process quality assurance also need to be considered (example: the logic of the product requirements document, such as with other projects have a certain interaction, whether comprehensive consideration). Multi-angle considerations, how the system architecture relates to dependent services, how to deliver, etc... Know exactly what you want to test, clearly and plainly.

Say the test focus, a product is a version of the test cycle due to a variety of factors, will always be less than a few days, in that progress under the conditions of tension, how to ensure the quality of products as far as possible, to ensure that the quality of the product is a matter worth thinking about, such as what is the product selling point, Which are the points that users most often care about, such as blood is the current version of the main push point and so on.

Finally, the test target, the whole process out of the function, is not the sea need other tests, such as compatibility test, uninstall installation test, performance testing, etc., according to the specific project to make ....

2. Determine the process testing strategy

First of all, to understand the overall research and development team's work model, waterfall or agile, which will have a direct impact on the test rhythm and process strategy.

Secondly, according to the project group organization mode, divide and develop the process test strategy, BVT, FT, IT, ST, rpt and so on.

A, BVT (build verification test), build verification test can also become smoke test, version build test is a version into the test process entrance, this part of the strategy is to develop a quick checklist, testing qualified to enter the test, Reject the test if it is unqualified (this will require early communication with the project team, of course). A test without a version-back strategy is a bad experience.

B, FT (Feature test), component (sub-functional module) testing, for some teams, not all functions are developed together, they may be distributed in a subset of sub-teams and branches. The test strategy for this place is to maintain a smooth communication with the product and research and development, ensuring that each measurement is combined with the latest skeleton code and covers as much detail as possible of the functional points of the entire sub-function module.

C, IT (integrate test), integration testing, and TF merge skeleton code to the FT branch is the opposite, this place is merging FT branch code into the backbone code, the validation of the strategy focus on the new function to the impact of the existing functions.

D, ST (System test), for the last version of the system test. There's nothing to say, this is the test that most people do every day, full-featured, full coverage.

E, PRT (prerelease test), pre-release testing, grayscale testing, both formally release the small batch of user testing between the multichannel market, this phase of timely follow-up feedback.

3. Identify available tools

First, what test management tools are available (such as test management, use case management, continuous integration, bug management, and so on), and which test tools exist (APP/API automated test tools or frameworks, performance test experiences, or tools).

Secondly, according to the test scope to determine which tools this test needs, such as the need for app UI regression automation can choose which existing technology, API interface testing needs to choose the writing technology.

Finally, a comprehensive list of two tool lists determines the list of available tools and the list of required additions, and there are no special types of test tools required, such as proxy tools, database debugging tools, etc.

4. Confirm Available Test Resources

Test resources can be divided into two parts of people and things:

The human part, that is, the project will have several people involved, including the full participation of several, midway into or out of several, each of which has the test skills and project experience.

Part of the material is to confirm the testing process of the equipment required, service scheduling, whether the need to apply or purchase. Ensure that the required resources are available at the beginning of the test.

　　　

How to develop a test strategy