Test plan・Test Goal (Part 1) Delivery time, cost and product quality
- 1. Write test goals concretely and quantitatively in the software test plan
- 2. Test delivery goals are subdivided and used for milestones
- 3. Easy to manage using utilization for test cost targets
- 4. Set goals for product quality to be tested
- 5. We also use process quality, work quality and control for test goals
Write test goals concretely and quantitatively in the software test plan
When making a software test plan , the next thing to decide after the test policy is the test goal . The first test goals to be determined are delivery time, cost, and product quality , which should be determined as concretely and quantitatively as possible.
As with software development, software testing is difficult to see progress and results, so if you do not manage it well, you will not get the results you planned. To the management, the goal target is quantitative and specific because it is easy to do is better, is good for the quantitative ones goal of the test is also a as specific as possible.
There are various ways to set test goals, and this is not the correct answer, so you need to think about goals that are suitable for each software development project each time. However, setting test goals can be difficult if you’re not used to them, so here are some examples of test goals that Father Gutara has seen so far. Please use this as a reference when you set goals.
Test delivery goals are subdivided and used for milestones
Test delivery times and costs are essential items when planning a test, so set goals at the beginning of your test plan . First of all, the delivery date of the test is decided, but like the development of software, it is better to subdivide the test into several types of tests, set the delivery date target for each, and then decide the total delivery date of 100 million votes.
There are various types of tests conducted by the test team, such as function / performance confirmation, stability confirmation, security confirmation, validation confirmation, etc. , and each test may be performed in turn . It may be carried out at the same time. The delivery date target for each of the multiple tests planned is set, and when all the test results are complete, the delivery date target for the entire test is determined to determine whether or not the test can be completed.
In addition to the overall delivery target, you can set delivery targets for multiple tests and use them as milestones for test work, which can be used to manage the test progress schedule . If the milestones are achieved as planned, there is no problem with progress, and if there is a delay in achieving the milestones, there is something wrong with the schedule.
Easy to manage using utilization for test cost targets
Once the delivery date for each test is decided, the equipment, environment, and personnel required for the test can be identified and a plan for allocating the equipment, environment, and personnel can be made. Since the equipment, environment, and personnel that can be used are limited , adjust the usage schedule as well as possible to reduce the free time of expensive equipment and equipment, or wait for test personnel due to equipment and environment waiting. You will have to devise a plan so that you do not.
The cost required to secure the necessary equipment, environment, and personnel for the required period is the test cost, but the cost is managed as a target after the cost is estimated at the time of planning and the budget is allocated. There are few . If you don’t have the necessary equipment, environment, and personnel, the test will not proceed, so it is a little difficult to use the cost itself for management.
However, if you estimate the operating rate of equipment, environment, and personnel according to the cost estimate and use this as a goal for cost control, it will be relatively easy to manage the test cost even during the test. For example, if you prepare a certain equipment for 20 days from October 11th to 30th, and you plan to have 4 days not used for testing due to environment and personnel reasons, the target of the operating rate of this equipment is Is 16th / 20th, so it is 80%.
If something goes wrong during the actual test and the number of days not used for the test increases by one day from the original plan, the utilization rate will be 75%, which is lower than the target. It would be nice if we could continue the test in that state and complete the planned test, but if there is a problem with the schedule or test content, we have to take some measures. Since it is management to take measures against deviation from the plan, it will be easier to perform test management if the operating rate is set as the cost target.
Set goals for product quality to be tested
Next to delivery time and cost as a test goal, the product quality goal of the software under test is required . The product quality goal is greatly influenced by the quality of the software, so it is better to think of it as a goal for deciding whether to continue or interrupt the test, rather than the goal of the test itself. Let me give you some examples of product quality goals that you often use in your tests.
(1) Bug detection rate
The most commonly used bug detection rates are the bug detection rate (X bug / test) for the test item and the bug detection rate (Y bug / KLOC) per 1KLOC of source code . The former bug detection rate per test item is used to see the quality of the test design on the premise that the software is stable to some extent . If the actual value is too small compared to the target value, it may not be possible to detect enough bugs, so it seems good to check if there is any problem in the test design.
The latter bug detection rate per 1KLOC of source code is used to see the quality of the software under test , assuming that the quality of the test design is stable to some extent . If the actual value is too large compared to the target value, the quality of the software under test may be quite poor, so it may be better to stop and consider whether to continue the test as it is.
(2) Bug fix rate
If the test finds a bug, debugging work will begin to fix it. It would be nice if all the bugs found were fixed within the day, but in many cases it takes days to fix, so the cumulative number of bugs fixed will be less than the cumulative number of bugs found . ..
Ideally , the bug fix rate calculated by the cumulative number of fixed bugs / cumulative number of found bugs is 100%, but in reality this is not the case. If a large number of bugs are detected and debugging cannot catch up, and unfixed bugs accumulate, the value of the bug fix rate will drop to 70% or 60%.
Therefore, set a target value for the bug fix rate, such as what percentage to maintain the bug fix rate throughout the test period, and what percentage to bring the bug fix rate to at the end of the test . You can manage the product quality of the software under test by managing the test using this.
We also use process quality, work quality and control for test goals
In addition to the delivery times, costs, and product quality introduced so far, we may also use process quality, work quality, and control as testing goals, which we will discuss in the next article.