Technique for automatically generating a software test plan

Details Technique for automatically generating a software test plan Technique for automatically generating a software test plan

1999-09-10

2003-04-08

Beausoliel, Robert (Department: 2184)

Error detection/correction and fault detection/recovery

Data processing system error or fault handling

Reliability and availability

C717S101000, C717S124000

Reexamination Certificate

active

06546506

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer software testing, and deals more particularly with a method, system, and computer program product for automatically generating a software test plan. The computation of test duration is based on the number of hours spent executing test scenarios and identifying defects, and the number of test personnel available.
2. Description of the Related Art
Software development occurs in stages, from designing a solution to an identified problem or need, to writing code to implement the solution, to testing the code. Planning the cost and duration of each of these stages is critical in determining the business case for proceeding with the software development. The duration information is also critical for properly planning the date of availability of the software.
Testing is an important part of the software development cycle. The motivation for testing software is to raise the quality and reliability of the program, and to establish confidence that the program does what it is supposed to do. Assuming that programs contain errors, the purpose of testing is to find as many of the errors as possible. Thus, testing may be considered as the process of executing a program with the intent of finding errors.
Planning the duration of the test phase is an especially important part of planning for a software development project, since this phase comes immediately before product shipment or availability to the market. Often, the duration of a test in a test plan is computed by assuming that testing should account for some fixed percentage of the total development cycle. While this approach has the advantage of simplicity, it has a number of drawbacks. First, if the overall estimate of duration of the development cycle is inaccurate, the duration of the test phase will only be accurate by happenstance. Second, this approach ignores the number of test personnel who are available and their experience levels. Obviously, if an insufficient number of testers are available, or those who are available are inexperienced, it is less likely that the testing will be completed during the fixed-percentage timeframe than if the test phase has been staffed with a sufficient number of experienced testers.
Another approach to computing test phase duration is to ask the assigned testers working on the project to estimate how much time each will need to complete the testing of his or her portion of the code, and then totaling those estimates. This approach also has a number of drawbacks. It assumes that all the testers have been assigned early enough in the development cycle to provide estimates in a timely manner, and that these testers have the experience and a sufficient understanding of their assigned code to make good estimates. Often with software projects, plans for the overall development cycle are put in place before all the testers are available and assigned, since test is a later phase of the software development process. In addition, test personnel may be recently hired employees or subcontracted temporary employees, since the test phase deals often with exercising the product using the external interface and thus can be a good place to train people who are unfamiliar with the product. Because of these factors, relying on the testers' “best guesses” as to test phase duration is unlikely to be accurate, and will lead to a plan that ends up being unachievable.
Yet another approach to computing test phase duration is to estimate the number of lines of code under development, often expressed in terms of “KLOC” (i.e. thousands of lines of code).
However, in addition to being affected by several of the factors previously discussed (such as ignoring tester availability and experience), this approach typically does not account for such factors as inaccurate estimates in the overall number of KLOC, whether the code being tested is complex or relatively simple, whether the code to be tested is completely new or is existing code that has been modified, etc.
Accordingly, what is needed is an improved technique for estimating test phase duration for generating an associated test plan.
SUMMARY OF THE INVENTION
An object of the present invention is to provide an improved technique for estimating test phase duration.
Another object of the present invention is to provide this technique by defining a computational model based upon the tasks performed by test personnel.
Yet another object of the present invention is to provide this technique by defining a computational model based upon the time spent executing test scenarios or test cases and documenting discovered defects, and the number of testers available.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a system, method, and computer program product for estimating test phase duration. This technique comprises: obtaining productivity information for a software project to be tested, this productivity information comprising an average number of hours required for executing a test scenario, an average number of hours required for identifying and documenting a defect, and a productivity factor of test personnel; obtaining input values for the software project, these input values comprising a projected number test scenarios, a projected number of defects, and a projected number of test personnel; computing a number of weekly hours available for work; and generating the software test plan using the obtained productivity information and the obtained input values. Generating the test plan further comprises: computing a duration of the testing of the software project when the duration is not known; and computing a risk factor for the testing when the duration is known.
Computing the number of weekly hours available for work preferably further comprises: computing a number of hours available per week per tester by multiplying a number of hours per work week by the productivity factor; computing a diminishing return value by multiplying 10 by a result of subtracting Y
x
from 1.0, where Y is a diminishing return productivity factor and x is the projected number of test personnel; and setting the number of weekly hours available for work to a product of the computed number of hours available per week multiplied by the computed diminishing return value. Preferably, the diminishing return productivity factor is 0.9.
Computing a duration further preferably comprises: computing a total of hours needed for test scenario execution by multiplying the average number of hours required for executing a test scenario by the projected number of test scenarios; computing a total of hours needed for defect identification and documentation by multiplying the average number of hours required for identifying and documenting a defect by the projected number of defects; computing a total hours needed by adding the computed total of hours needed for test scenario execution and the total of hours needed for defect identification and documentation; and computing the duration in weeks by dividing the computed total hours needed by the number of weekly hours available for work.
Computing a risk factor preferably further comprises: computing a capacity for defects, and computing a risk. Computing a capacity for defects may further comprises: computing a first product by multiplying the known duration by the number of weekly hours available for work; computing a second product by multiplying the average number of hours required for executing a test scenario by the projected number of test scenarios; computing a time available for defects by subtracting the second product from the first product; and setting the capacity for defects to the computed time available for defects divided by said

Affiliated with

Also associated with

Rating

Technique for automatically generating a software test plan does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Technique for automatically generating a software test plan, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Technique for automatically generating a software test plan will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3017883