On risk management of software testing

Summary: Software Testing , as an important means to ensure the quality of software, is attracting more and more attention, while there are risks in software testing projects, if we can pre-emphasize the risk assessment and develop a positive response plan to the risk, we can Minimize risk or reduce risk.

　　Key Words: Test risk ; test management ; Software testing

The complexity of the software itself and the nature of the test itself determine the large number of risks that occur during the implementation of the test activity, which can affect the success or failure of the test activity, and may lead to the entire project failing at a critical time. Therefore, the management of testing risk is attracting more and more people's attention.

1, the inevitability of the existence of risk

The risk of software testing projects comes from the characteristics of software and testing itself.

1.1 Features of the software

1) software products are not visible: software project development progress and software quality control process is difficult to measure, make the management of software is difficult to grasp;

2) software production process in various forms, there is no absolute right form: different software development projects, should take a different or specific software development process. However, at the beginning of the project development can not determine the correct form, only according to the characteristics of the project and development experience to choose, and in the development process of continuous adjustment, really suitable for the development process of the software can only be determined at the end of the project development;

3) Large-scale software projects are often "disposable": The Project One-time features so that the past experience can not be widely used for reference. The only way to control the risk of software management is to set up a monitoring system to carry out effective risk monitoring and management.

1.2 Characteristics of the test

1) Complete testing is impossible: in limited resources and time conditions, to find out all the software defects and errors, so that the software tends to perfect is impossible, the main reason is that the input is too large, the output is too many, the path combination too;

2) test virus-like immunity: software defects are as scary as viruses, and the more tests they use, the stronger the immunity, and the more difficult it is for software test engineers to find more software defects;

3) testing is a "generic concept": Software testing covers the entire software lifecycle, including requirements analysis, summary design, etc., to ensure that each stage is tested and that testing itself requires evaluation and supervision from third parties to ensure the reliability of the test;

4) 80-20 principle: 80% of software defects often survive in 20% of software modules. We can only detect and evade 80% software defects at this stage of system analysis, system design and system reality. In the next system test , we can help us find 80% of the remaining defects, and the remaining 4% defects will only be exposed after a wide range of long-time use after the system is delivered. Therefore, software testing can only guarantee to discover as many software defects as possible, but can not guarantee to discover all software defects;

5) The inevitability of defects: not all software defects can be repaired successfully due to the error correlation in software testing. In the defect repair process will inevitably introduce new errors, in addition, in the process of repair, we will often be limited by the time, cost and other factors, resulting in the eventual impossible to completely repair all software defects.

2. Risk Assessment

There are two basic aspects of risk management: risk assessment and risk control.

Risk assessment is based on risk identification, the identified risk assessment, mainly from the following four aspects:

1) Risk probability analysis, that is, the possibility of risk to set a scale, such as high, high, medium, low, very low;

2) Describe the risks and predict the possible impact or loss of the software products and test results after the risk occurs;

3) Determine the correctness of the risk assessment, to the performance of each risk, scope, time to make the best possible accurate judgment;

4) According to the product of loss (impact) and risk probability, to determine the priority level of risk, customized risk response measures.

3, the principle of risk control

Risk control is based on the risk assessment, the main working principles are:

1) for some avoidable risk, such as the test case execution rate is not up to 100%, you can by the development of test specifications, require testers to strictly follow the test case to carry out testing, and record use case implementation, to avoid such risks;

2) Some unavoidable risks, taking measures to reduce the risk, especially the higher level of risk, to convert it into a lower level of risk without causing serious consequences;

3) In all things pre-set, good risk management plan in advance, when the risk becomes a reality, can better avoid, transfer or reduce risk;

4) to develop a contingency and efficient solution to the risk management.

4. Software Testing risk analysis and management method

The software lifecycle includes six phases of problem definition and planning, requirements analysis, software design, program coding, software testing, and operational maintenance, and the rigor of any aspect of software testing may increase the risk of software testing activities. There are also a variety of risks in software testing activities, including the risk of changing requirements, testing process risk, testing organization, and personnel risk.

4.1 Risk of change in requirements

In the implementation of software testing projects, especially long-lasting large projects, there will inevitably be changes in demand. How to grasp the change of demand and reduce the risk caused by the change of demand becomes the key to the success of the whole project.

Management of requirements change of 4.1.1 Software testing project

1) Set the reference standard for change of requirements and baseline the requirements. When the software test project team confirms that a requirement change is to be made, the change request record of the client is archived using the standard change Request form. Each change should be made on the basis of a requirement baseline.

2) after receiving the request from the client, the Software test project team establishes the Project change Control Committee (CCB), which is responsible for evaluating the impact of the project changes, including the human, material, capital, management, time, quality, workload and other internal factors of the project, as well as the completion time of the capital and the entrusted party's requirements. , and the impact of various aspects of the project liability situation.

3) After the change has been determined, select a feasible implementation plan. In order to minimize the risk of project changes, we aim to fine-tune the objectives, budget, team and project progress of the test project within the smallest possible range of changes.

4) After the change of requirements, to re-determine the new requirements baseline, the affected software plans, products, activities and so also to make the corresponding changes to ensure and the latest demand consistency.

4.2 Testing Process Risk

The main risks in the test work are:

1) Temporary or abrupt changes in demand, resulting in design changes and code rewriting, making the test time is not enough;

2) The test case does not get 100% execution;

3) The quality requirements or product characteristics of inaccurate understanding, resulting in the test Range analysis error, the results in some places are always not tested or verified standard is not correct;

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

5) The test case design is not in place, ignoring some deep-seated logic, boundary conditions, user scenarios, etc.

6) The test environment and the actual production environment can not be fully consistent, resulting in the error of the test results;

7) Some defects occur frequency is not 100%, not easy to reproduce; If the code quality is poor, software defects are many, the possibility of missing defects is large;

8) Regression testing is generally a selective execution of some test cases, which entails risks.

The first 3 risks can be avoided by the early investigators or testers to strengthen communication with the customer or to establish a strict system to avoid, and for some unavoidable risks, take some effective test risk control methods to minimize the risk, such as the test environment is not correct, you can list all the items to check beforehand, After the test environment is set up, the other people are checked by the listed entries, and the "uncovered defects" that always exist in the program can be reduced by increasing the coverage of test cases (e.g. 99.9%) to reduce the risk, and on the eve of a frequently occurring product release, a new feature that is not very important Defect, you can remove the new feature to transfer the risk of a defect in an existing feature that may be caused by modifying this flaw. Regression testing can be avoided only by performing some of the risks associated with a use case, but it is generally present for a comprehensive consideration of time or cost.

Risk management planning and risk control strategies can be better avoided, transferred or reduced in advance:

1) in the implementation of the project plan, to do resources, time, cost estimates, should leave leeway;

2) before the start of the project, to develop a risk management plan, focusing on the boundaries may be changed, difficult to control factors;

3) Pay attention to the training of personnel, to each key technical position personnel training reserve personnel, to ensure that the project is not affected by the movement of people seriously;

4) Establish working mechanism and document standards, ensure the timely production of documents, facilitate the sharing and transfer of project knowledge;

5) The work of mutual review, different testers in different test modules exchange each other, timely detection of problems;

6) Daily tracking of all work processes, timely detection of signs of risk to avoid risk.

4.3 Testing organization and personnel risks

4.3.1 Testing Organizational risk

Testers are not independent of the developer, and the degree to which the tester is independent and developer will affect the test results.

1) Set up a special testing organization;

2) Develop a special test management process and quality Assurance manual, standardize the testing process, to ensure the quality of testing;

3) commissioned a dedicated testing organization to perform testing activities.

4.3.2 Personnel risk

Test projects, especially those with longer periods, are almost inevitably confronted with the flow of people, thereby increasing the risk factor for project failure. Early prevention is a basic strategy to reduce the risk of such personnel. The following is a detailed introduction to the control of personnel risk from the perspective of third-party testing:

1) Assign a project manager or project Manager Assistant to coordinate the project managers to manage the project and reduce the risk of staff turnover in key positions. However, it is generally recommended that this redundancy strategy be used to prevent personnel risk in the more important position of project manager, otherwise the project cost will be greatly increased;

2) Establish a good document management mechanism, including project team progress document, personal progress document (test log), version control document, overall technical documentation (Test strategy, test case), personal technical documentation (test execution record, defect report), etc. In the event of personnel changes, the replacement team can take the job as soon as possible according to the complete documentation;

3) Control the proportion of the project team of Chinese and foreign or part-time personnel, and the core part of the work should be as far as possible from the full-time staff to serve to reduce the impact of part-time personnel on the project team's instability;

4) To strengthen the technical exchange in the test project team, regular meetings of the project, so that the Test team members can be familiar with each other's work and progress, be able to replace each other's work when necessary;

5) Provide the best possible basic environment for the project test work, such as treatment, good interpersonal relationship and working atmosphere in the project team. A good working environment can not be neglected to stabilize the project team and improve production efficiency.

4.3.3 Risk of outsourcing personnel

1) To formulate relevant management process documents, standardize the activities of outsourced personnel, prevent risks, avoid outsourcing risk;

2) Monitor the whole test activity through the way of the outside supervision team;

3) Through testing the intermediate deliverables of the test to ensure the quality of testing, such as: the design of the test cases to review, the written test code checks, check the test execution of the log, etc.

4) in the form of outsourced testing, in addition to avoid the contractor project personnel leak, but also pay attention to the data transmission process information confidentiality. In the use of outsourcing testing, it is inevitable to carry out a variety of information transmission, may be the telephone, e-mail communication, may be the software version of the transmission, in the circumstances allow the use of VPN, and so on. If necessary, encrypt the data that is being transmitted.

5. Concluding remarks

The risk in the testing process always exists, the paper identifies and controls the major risks in the test activity, and determines the targeted measures to avoid the risk, or minimize the risk. To do a good job in risk management, we must completely change the management of the test project, establish a preventive management consciousness, and combine the practical work to analyze the risks, summarize the various risk measures, guide the practice and reduce the risk of product quality.

Reprint: http://blog.chinaunix.net/uid-16844439-id-3379355.html

On risk management of software testing