Test Estimates

There are two types of Test Estimation Approaches

1. Bottom-up Estimation
2. Top-down Estimation

Top-down Estimation

In this approach the effort (cost) of the whole project is estimated first. The estimation of the overall effort is made based on the type and scale of the project and on similar projects that were carried out before. The estimation for phases or activities or subsystems is calculated as a percentage of the whole. Past data and present project characteristics are used to adjust the estimate to meet project specific situation

Bottom-up Estimation

First the size, effort and schedule of each phase or activity and work products produced is estimated. The effort (cost) of the total project is calculated by aggregation. This approach is suitable for projects where a detailed knowledge of the product to be built and the project specific process and complete work breakdown structure is available. Past data and present project characteristics are used to adjust the estimate to meet project specific situation.

"Effort" can be computed using the following simplified relationship:
Effort = Size * Productivity

Where "size" is the estimated size (KLOC or FP) of the current project
"Productivity" parameter (Person Months per KLOC)

Size Estimation

The software size is estimated in terms of "Lines of Code" (LOC) or "Function Points" (FP). LOC or FP data is used in two ways during project estimation:
1) As an estimation variable that is used to "size" each element of the software
2) As baseline metrics collected from past projects and used in conjunction with estimation variables to develop cost and effort projections. Apart from LOC or FP component measures like classes or objects can also be used.

Some times the software size is estimated in terms of physical size units, such as:
• Number of screens and menus
• Number of reports
• Number of forms
• Number of pages of documentation
• Impacted lines of code
• Impacted business processes

Estimating Lines of Code (LOC)

LOC measures are programming language dependent. A software product may consist of developed code, modified and reused code, and commercial off the shelf software code.The size of developed code, modified and reused code and commercial off the shelf code need to be estimated separately. The nature of effort required for developing new code is different from that of modifying and integrating reused code or integrating with commercial off the shelf software.

The greater the degree of partitioning, the more likely that reasonably accurate estimates of LOC can be developed.

Estimating Function Points

Function Point method is independant of technology.

Effort Estimation Using Simple Estimation Relationships

In this method of estimation data from past projects (similar projects) is used to establish simple equation for estimation of effort. The following metrics from the past projects may be used for estimation:

• Effort (person-months) per KLOC (or FP)
• Documentation (Pages) per KLOC (or FP)
• Defects (Delivered or In-process) per KLOC (or FP)

The software product size specified in KLOC or FP may be used. The size estimate could be a one-point estimate (most likely) or could be based on a three-point estimate (Optimistic, Normal (most likely), and Pessimistic). Usage of three-point estimate for size would give a range of values and also the "Expected Value" for effort. Using simple estimation relationship effort can be computed in the following way:

• Identify relevant past projects and collect their metrics data
• Analyze the metrics and arrive at a common value (simple average or weighted average) across the projects for each metric.
• Multiply size by effort per KLOC metric value to get nominal effort for the new project
• Multiply size by documentation (pages) per KLOC to get size of documentation
• Multiply size by defects (delivered or in-process) per KLOC to get projected defect values

Effort Estimation Using Wideband Delphi Method
This method is suitable for new projects where no past project data is available. Using this method effort can be estimated in the following manner:

• Identify a team of experts (resources with relevant application and technical skills and knowledge) and a facilitator to facilitate the estimation process
• Provide the software product details and other technical documents to the experts
• An overview meeting is conducted by the facilitator to discuss the project scope, work involved, assumptions and estimation issues.
• Each expert prepares a three-point size estimate (LOC or FP) using the size estimation procedure explained earlier. The expert also prepares justification for arriving at the estimation
• Based on the size estimate the effort is also estimated by the expert using simple estimation relationship or by judgment using personal experience
• Suitable effort adjustment buffer % of effort) is to be provided to take into account complexities and uncertainties associated with product, platform (technology), personnel and project.
• The estimates are given to the facilitator, who tabulates the estimation data and the justifications given by each expert and computes the median value and range of estimates
• The tabulated results and justification report given to each expert provides details of median estimate, range estimates and the concerned experts estimate. The other expert's estimates are also given in the report anonymously.
• The experts study the results and justifications and meet to discuss in detail their estimates
• Based on the deliberations and new insight each expert may revise his estimate
• The process iterates again till all experts agree to a common three-point estimate
• Complexity is defined as High, Medium and Low based on the requirements of the project and a. Number of technologies involved, b. Familiarity of team with technologies, c. Bleeding edge or well established technology and d. Number of technical interfaces/services based on this complexity levels to be defined like : High, Medium and Low
  

Effort Estimation Using Analogy
Analogy method assumes that some resemblance and commonality exist between the new project and past project(s). This method can be used for size and effort estimation in the following manner:

• Study the project scope and details of the new project
• Identify at least one project executed in the past that is analogous to the new project
• Analyze the new and old projects software product to arrive at common features and differences between them
• Obtain the metrics data of the selected past project on size, effort, defects, etc.
• Estimate size (LOC or FP) of the new software as per the size estimation method
• Specify optimistic, normal, and pessimistic size of the components (Use the Component Size and Complexity Entry form in QMS to record the size)
• Specify optimum, normal, and pessimistic effort required for coding of each software component. Coding involves code development, compilation, and code review tasks only.
• Identify and provide for contingency to account for impact of risks on software size.
• Identify and take into account inclusion /integration of off-the-shelf/reusable components and its impact on software size.
• Develop expected value of total size and effort for coding
• Provide suitable adjustment buffer (% of effort) to take into account complexities and uncertainties associated with product, platform (technology), personnel and project.
• Obtain the phase / activity wise effort distribution (%distribution) from the selected past project.

Project Schedule is calculated using:

Schedule= Allocated Effort / (8 * No. of resources)

Estimation for Bug fixing

Many times bug fixing may involve changing (adding/deleting/modifying) few lines of code. The size of the change may be trivial. Hence size estimate is not required. However the effort required for research activity and solution development may be very high. Techniques such as simple estimation relationship can be used for effort estimation.


QA Project Effort = (Test planning effort) + (Test design effort) + (Test design maintenance effort) + (n * software build test effort)

Test Design Effort = No. of test cases * Effort required per test case