How to develop a software project test plan

xiaoxiao2021-03-06 19

From: http://www.yesky.com/softchannel/72342393369657344/20050319/1924087.shtmlauthor: Zhong Hua Date: 2005-03-21

Abstract With the testing direction of standardization management, the test plan has become one of the important tasks that the test manager must complete, this article explores how to develop a software project test plan according to the practice of practical experience. Keyword Test Plan Change the Text Software Test Plan as a subprogram of the software project plan, which is planned in the initial period of project startup. In more and more software development, the software quality is increasingly valued, and the test process is also nesting from a relatively independent step in the entire life cycle, so that how to plan the testing of the entire project cycle; How to rose test work to test management, depending on the formulation of the test plan. The test plan has also become the foundation of the test work. A good test plan can function as follows 1. Avoid the "event drive" 2 of the test. Make the test work and the entire development work 3. Resources and changes in advance Templates that are controlled as a controlled risk test plan are different in all companies. It is found in personal practice. The problems in the test plan formulation are similarity. The following focuses on these similar problems talk about how to develop software Project test plan. Question 1: The test phase is divided into usually software projects. Basically, the "waterfall" development method is basically used. Under this development method, the main activities of each project are relatively clear and easy to operate. The entire project life cycle is "Demand - Design - Coding - Test - Publish - Implement - Maintenance". However, in the development of test programs, some test managers are not very clear about the phase of the test, often encountered problems is to make tests to systematically test, or put various types of test design (test case writing and testing Data Preparations All put into the "test phase" of the lifecycle, which causes the problem to waste the project schedule that can be parallel in the development phase, and there is insufficient testing in the other hand. The reasonable test phase should follow the following division:

According to the picture above, the corresponding phase can be synchronized to perform the corresponding test plan, and the test design can also be combined to implement parallel, test implementation, to perform testing, will be coherent after development. It is worth noting that unit testing and integrated tests are often borne by the developers, so this partial class division may be arranged in the development plan rather than the test plan.

Question 2: System Test Stage Schedule

The division phase is clear, and the problem comes is how long is the test? Standard engineering methods or CMM methods are estimated to workload, and then the specific estimate is obtained. But this method is too complicated, and you can discuss it again. An operational simple method is to convert according to the active time of the test implementation, the conversion method is about 1: 1.1 to 1.5 or so in the first phase. For example, for the test manager, because the development plan may contain unit testing and integration testing, the system test is probably 1 to 1.5 times the coding phase (including unit testing and integration test). The advantage of this approach is that the shortcomings are too much moisture, difficult to quantify, depending on the schedule of the project plan. Then, another simple method that can be used is an empirical assessment. The evaluation method is as follows:

1. Calculate the number of pages of the demand document, give the number of pages of the system test case

Demand page: System test case page number ≈ 1: 1

2. Calculate the writing system test case time by the system test case page

Writing system test case time ≈ system test case page number × 1 hour

3. Calculate the execution system test case time write system use case: Perform system testing ≈ 1: 2

4. Calculate the time of regression test

System testing time: Return to test ≈ 2: 1

Note: The above ratio is a personal engineering experience value, and the test manager that needs to be corrected can collect data in specific practice.

Based on the above method, it is known to be known, can be used to calculate the unknown, suitable for demand is known and relatively stable; the disadvantage is that the project is in R & D status, is more difficult to calculate when the demand is unclear. The current set is added to the description: the number of demand documents is 500, the number of system test case pages is estimated to be 500, and the system test case time is 500 hours, the execution system test case time is 1000 hours, the regression test takes 500 hours, plus A total of 2000 hours, according to 8 hours a day, a total of 250 working days / person; if a month is 22 working days, a total of about 11 people / month, that is, it takes about 3 months to complete the workload. . Of course, this is all the time required for system testing. According to the principle of the test phase, the design time can be carried out simultaneously with the development of development, and the time scheduled in the test phase is 1500 hours, 4 people, 2 months, 2 months.

(The test manager is writing the test schedule when writing the test plan, the program start / end time is often divided into the specific time division of 20050101-20051201, the problem caused by the problem is that the test plan time has to be adjusted at any time when the project plan is changed. This change may be frequent and trivial, can replace the way to cancel this way, use 30 working days / 2 people or 2 people this workload method, so that only need to track in the project plan The specific start time of the stage, does not have to repeatedly modify the test plan.)

It is worth noting that most of the domestic companies have insufficient test time, it is impossible to operate in this ideal ratio, because the test execution is actually impossible to occupy 1/2 of the entire project cycle, even shorter than it Any project phase time. Even if Microsoft's test end principle is not all necessary tests, but the test is over the day of the plan! In the absence of insufficient test time, you can refer to the method of change the following project plan, because the plan change also involves insufficient test time.

Question 3: Change control

The test plan has changed the way to test according to the task. Therefore, in order to make the test plan implementation and implementation, the test team must keep track of software development process, preparing for the product, the purpose of testing the plan, it is, it is emphasized The planned test strategy is tested, eliminating the temporary temporary trend of the task. In this case, the test plan emphasizes the control of the change is particularly important.

Change comes from the following aspects

1. Change of project plan

2. Demand change

3. Test product version change

4. Test resource change

The risk of the test phase is mainly the uncertainty caused by the above changes, and the effective response to these changes can reduce the chances of risk. It is necessary to plan itself not a paper document that is empty talk and blank, and the foresight and prior prevention of uncertain factors must be available.

For changes in the project plan, the project manager must recognize the test team is also a project member, so that the project is notified in time, so that the entire project must be labeled. The project plan change generally involves a schedule change. Regrettable is that the delivery period is established for the principle, the project manager has to reduce the test time, so that the test time is compressed. In this case, the test manager often stubbizes the sole method of progress reduction is to report to the superior and subjectively believe that the product quality will fall, this approach and idea is not necessarily correct. Due to lack of time, it is not "perfect" to implement all tests. In order to ensure quality, the first method is to adjust the test strategy and test scope in the test plan, and the test manager often ignore this section of the test plan. The purpose of adjustment is to reckon unimported test part, to change the order of the test and reduce the test size, and recombine the test type, try to do the most important part of the test time, you can leave the ignored part to confirmation test or site test. Other countermeasures include reducing the resistance of entering the test, such as reducing the system test admission criterion in the test plan; step-by-step submission test, such as reducing iterative incremental testing; reducing regression testing, such as developers real-time modification, in test plan The defect repair response time and process is agreed; and the company QA discussion simplifies configuration management, skip formal release links; defects are local regression rather than re-test. Second: The most inevitable process in the process is the change in demand. So, is it possible to control and constraint in the test plan? The answer is not necessarily. When the plan is formulated, if the project demand is dynamically changed, the test case section will be described. Many test managers often distinguish between test cases and test data when preparing test cases, and therefore, the problem is to be abolished when the demand changes. At this time, false items facing a demand dynamic must be described in the plan to change the test (design) mode of demand changes, such as use cases and data separation, process, and interface separation, dictionary and data elements separation. Way, then wait until the final demand is determined to refine the test design; another aspect is to make a convention for a change cycle - especially in the implementation of the test phase discovery demand - the maximum frequency of the change, the maximum frequency of the change, and the boundaries of retest the retest. Planning to a certain extent can reduce the loss of investment caused by unpredictable demand changes. It is worth noting that the additional work of the test manager is to remember to record on the demand tracking matrix.

For changes in the test product version, except for part due to changes in demand, it is likely to be due to problems or configuration management caused by modification defects. As we all know, the test must be based on a stable "baseline", otherwise it is considerable because of repeated modification of the waste of test resources and developing resources. The reasonable test plan should add a test update management chapter in the chapter, which is clearly updated and paused the principle of the test. For example, small version of the product update cannot be greater than three times a day, a relatively large version cannot be greater than once a week, stipulating the emergency release product is limited to what type of modification or change, who is responsible for unified maintenance and synchronization update test environment. The test plan usually develops access and number of guidelines. It is not enough. When you consider the test pause, the product error release or server data update is an example. If the test manager does not track, the test group is waiting when the test manager is not tracked. Test and no one notifies the continued testing, so it is necessary to increase the update cycle and pause test principles.

Finally, the changes in test resources are the risk of the test group instead of development group, when the test resource is insufficient or conflict, the test department is impossible to arrange so many people and sufficient time to participate in the test plan, in the test plan Similar to the lack of test time. No test manager is willing to take a test work of insufficient resources, can only be said that the company has quality-oriented system or project manager's emphasis on product quality, how to determine the size of the test resource investment, the final product quality detention is not only Test manager. In order to eliminate this risk, in addition to the lack of time, the test scale is reduced, and the test manager must indicate the resources of the human resources and test environment, otherwise this problem must be used as Risk record. Avoiding risks may be: 1. The needs of the project team and the implementation personnel participate in system testing;

Second, the dispersion of different module developers conduct cross-system testing or borrow other project developers;

Third, organize the client to confirm the test or release the beta version.

Although the test plan is described above to "perfect" as much as possible, it is still the problem of management and monitoring of the test plan. Another time to put more time does not guarantee the implementation of this plan. A good test plan is half of success and the other half is the implementation of the test plan. For small items, a more easy to operate test plan is more practical. For medium-sized and large-scale projects, the test management capability of the test manager is very important, to ensure that the implementation of the plan is not broken, the test manager Interpersonal harmony capacity, project test operation experience, the company's quality status is capable of producing a sufficient impact on project testing. In addition, the plan is also "dynamic"! It is not necessary to cover all factors, and it is not necessary to make this change in the additional "planned plan". The test plan cannot be set to the rear of the project, but the changes in the project, thinking and implementing in real time. According to the reality modification, then successfully implement it, this will achieve the ultimate goal of the test plan - guarantee the quality of the final product!