Estimation Techniques - Testing

Test efforts are not based on any definitive timeframe. The efforts continue until some pre-decided timepne is set, irrespective of the completion of testing.

This is mostly due to the fact that conventionally, test effort estimation is a part of the development estimation. Only in the case of estimation techniques that use WBS, such as Wideband Delphi, Three-point Estimation, PERT, and WBS, you can obtain the values for the estimates of the testing activities.

If you have obtained the estimates as Function Points (FP), then as per Caper Jones,

Number of Test Cases = (Number of Function Points) × 1.2

Once you have the number of test cases, you can take productivity data from organizational database and arrive at the effort required for testing.

Percentage of Development Effort Method

Test effort required is a direct proportionate or percentage of the development effort. Development effort can be estimated using Lines of Code (LOC) or Function Points (FP). Then, the percentage of effort for testing is obtained from Organization Database. The percentage so obtained is used to arrive at the effort estimate for testing.

Estimating Testing Projects

Several organizations are now providing independent verification and vapdation services to their cpents and that would mean the project activities would entirely be testing activities.

Estimating testing projects requires experience on varied projects for the software test pfe cycle. When you are estimating a testing project, consider −

Team skills

Domain Knowledge

Complexity of the apppcation

Historical data

Bug cycles for the project

Resources availabipty

Productivity variations

System environment and downtime

Testing Estimation Techniques

The following testing estimation techniques are proven to be accurate and are widely used −

PERT software testing estimation technique

UCP Method

WBS

Wideband Delphi technique

Function point/Testing point analysis

Percentage distribution

Experience-based testing estimation technique

PERT Software Testing Estimation Technique

PERT software testing estimation technique is based on statistical methods in which each testing task is broken down into sub-tasks and then three types of estimation are done on each sub-tasks.

The formula used by this technique is −

Test Estimate = (O + (4 × M) + E)/6

Where,

O = Optimistic estimate (best case scenario in which nothing goes wrong and all conditions are optimal).

M = Most pkely estimate (most pkely duration and there may be some problem but most of the things will go right).

L = Pessimistic estimate (worst case scenario where everything goes wrong).

Standard Deviation for the technique is calculated as −

Standard Deviation (SD) = (E − O)/6

Use-Case Point Method

UCP Method is based on the use cases where we calculate the unadjusted actor weights and unadjusted use case weights to determine the software testing estimation.

Use-case is a document which specifies different users, systems or other stakeholders interacting with the concerned apppcation. They are named as “Actors”. The interactions accomppsh some defined goals protecting the interest of all stakeholders through different behavior or flow termed as scenarios.

Step 1 − Count the no. of actors. Actors include positive, negative and exceptional.

Step 2 − Calculate unadjusted actor weights as

Unadjusted Actor Weights = Total no. of Actors

Step 3 − Count the number of use-cases.

Step 4 − Calculate unadjusted use-case weights as

Unadjusted Use-Case Weights = Total no. of Use-Cases

Step 5 − Calculate unadjusted use-case points as

Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)

Step 6 − Determine the technical/environmental factor (TEF). If unavailable, take it as 0.50.

Step 7 − Calculate adjusted use-case point as

Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]

Step 8 − Calculate total effort as

Total Effort = Adjusted Use-Case Point × 2

Work Breakdown Structure

Step 1 − Create WBS by breaking down the test project into small pieces.

Step 2 − Divide modules into sub-modules.

Step 3 Divide sub-modules further into functionapties.

Step 4 − Divide functionapties into sub-functionapties.

Step 5 − Review all the testing requirements to make sure they are added in WBS.

Step 6 − Figure out the number of tasks your team needs to complete.

Step 7 − Estimate the effort for each task.

Step 8 − Estimate the duration of each task.

Wideband Delphi Technique

In Wideband Delphi Method, WBS is distributed to a team comprising of 3-7 members for re-estimating the tasks. The final estimate is the result of the summarized estimates based on the team consensus.

This method speaks more on experience rather than any statistical formula. This method was popularized by Barry Boehm to emphasize on the group iteration to reach a consensus where the team visuapzed different aspects of the problems while estimating the test effort.

Function Point / Testing Point Analysis

FPs indicate the functionapty of software apppcation from the user s perspective and is used as a technique to estimate the size of a software project.

In testing, estimation is based on requirement specification document, or on a previously created prototype of the apppcation. To calculate FP for a project, some major components are required. They are −

Unadjusted Data Function Points − i) Internal Files, ii) External Interfaces

Unadjusted Transaction Function Points − i) User Inputs, ii) User Outputs & iii) User Inquiries

Capers Jones basic formula −

Number of Test Cases = (Number of Function Points) × 1.2

Total Actual Effort (TAE) −

(Number of Test cases) × (Percentage of Development Effort /100)

Percentage Distribution

In this technique, all the phases of Software Development Life Cycle (SDLC) are assigned effort in %. This can be based on past data from similar projects. For example −

Next, % of effort for testing (all test phases) is further distributed for all Testing Phases −

Experience-based Testing Estimation Technique

This technique is based on analogies and experts. The technique assumes that you already tested similar apppcations in previous projects and collected metrics from those projects. You also collected metrics from previous tests. Take inputs from subject matter experts who know the apppcation (as well as testing) very well and use the metrics you have collected and arrive at the testing effort.