Risks to be noted during software testing

When writing a test plan, consider the risks that may occur and propose countermeasures. So what are the risks to pay attention to? How to solve it? Some scenarios are listed below:

　　Design aspects:

Risk: (1) no detailed design instructions;

Solution: The tester will analyze the relevant design and requirements documents during the development phase, classify the functions of the general modules, analyze the business logic, and communicate with the developers in a timely and unclear place.

Risk: (2) There is no unified interface design specification.

Solution: Confirm the test standard with the project owner.

Development aspects:

Risk: (1) All module development is not unified design, developers have their own design method;

Solution: Verify the Standard method with the project leader, and all the inconsistencies in the standard way are submitted in bug form.

Risk: (2) demand change development.

Solution: It is recommended that changes in requirements be documented, changes to the requirements of no documentation, identified in a timely manner with the development owner in the course of testing, and documentation of the relevant changes.

　　Test itself:

Risk: (1) human resources;

Solution: Ensure a stable staffing arrangement.

Risk: (2) hardware resources;

Solution: Pre-analyze the hardware resources required for testing, apply in time, ensure the test work smoothly.

Risk: (3) version control;

Solution: Strictly control the version, and the bug is submitted in version. Any code updates are prohibited during the testing process and during the bug confirmation phase.

Risk: (4) Insufficient testing time.

Solution: Mobilize the testers to complete the test task and, if necessary, give the appropriate material rewards.

　　Testing risk is unavoidable and always present, so it is important to manage the risk of testing, and we must try to reduce the risk in testing, to ensure the best quality and meet the needs of customers. The main risks in the test work are:

First, the quality requirements or the characteristics of the product is not accurate, resulting in the test Range analysis error, the results of some places are always not tested or verified standard is not correct;

Second, the test cases are not fully implemented, such as some of the test cases are intentionally or unintentionally omitted;

Iii. temporary/abrupt changes in demand, resulting in design changes and code rewriting, testing time is not enough;

Four, the quality standards are not very clear, such as the applicability of the test, the beholder, benevolent see;

Five, the test case design is not in place, ignoring some boundary conditions, deep-seated logic, user scenes and so on;

Six, the test environment, the general impossibility and the actual operating environment is completely consistent, resulting in the error of test results;

Seven, some defects appear frequency is not 100%, not easy to be found; If the code quality is poor, the software flaw is many, the flaw that is missed is the possibility is big;

Viii. regression testing generally does not run all the test cases, is selective execution, will inevitably bring risks.

The first three risks can be avoided, while four to seven of the four risks are unavoidable and can be minimized. The last regression test risk can be avoided, but for time or cost considerations, there are generally.

There are some effective test risk control methods for the risk of the above software testing, such as:

Test environment can be checked by the first list of all the items to check, after the test environment is set up, by the other people by the listed items by check;

Some test risks can be very serious and can be translated into other low-risk cases that do not cause serious consequences. On the eve of a product launch, a serious flaw is found in a new feature that is not very important, and if this bug is corrected, it is likely to cause a defect in the original functionality. At this point the risk of dealing with this flaw is very big, the countermeasure is to remove that new function, transfer this risk;

Some of the risks are unavoidable, to try to reduce the risk, such as "defects not found in the procedure" The risk always exists, we need to improve the coverage of test cases (such as 99.9%) to reduce the risk;

In order to avoid, transfer or reduce risk, in advance to do a risk management plan and control the risk of the strategy, and to deal with the risk also need to develop some emergency, effective treatment plan, such as:

In doing resources, time, cost estimates, should leave leeway, do not use to 100%;

Before the start of the project, the risk management plan is to include some factors that may be changeable and difficult to control on the border;

(a) Training of reserve personnel for each key technical personnel, preparation of staff movements, and measures to ensure that the project will not be seriously affected and can continue to be carried out once the staff leaves the company;

Develop documentation standards and establish a mechanism to ensure that documents are produced in a timely manner;

Review all work and identify problems in a timely manner, including exchanging different testers on different test modules;

Daily follow-up of all processes, identify risks and avoid risks.

In order to avoid risk, we must completely change the management of the Test project, and set up a management consciousness of "precaution" or "prevention" to the risk of testing. Compared with the traditional software testing, the whole process test management method can not only reduce the quality risk of the product, but also can avoid the defect of the SOFTWARE PRODUCT, shorten the feedback period of the defect and the test cycle of the whole project.

Risks to be noted during software testing