”;
Test efforts are not based on any definitive timeframe. The efforts continue until some pre-decided timeline 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 validation services to their clients and that would mean the project activities would entirely be testing activities.
Estimating testing projects requires experience on varied projects for the software test life cycle. When you are estimating a testing project, consider −
- Team skills
- Domain Knowledge
- Complexity of the application
- Historical data
- Bug cycles for the project
- Resources availability
- 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 likely estimate (most likely 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 application. They are named as “Actors”. The interactions accomplish 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 functionalities.
Step 4 − Divide functionalities into sub-functionalities.
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 visualized different aspects of the problems while estimating the test effort.
Function Point / Testing Point Analysis
FPs indicate the functionality of software application 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 application. 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 −
| Phase | % of Effort |
|---|---|
| Project Management | 7% |
| Requirements | 9% |
| Design | 16% |
| Coding | 26% |
| Testing (all Test Phases) | 27% |
| Documentation | 9% |
| Installation and Training | 6% |
Next, % of effort for testing (all test phases) is further distributed for all Testing Phases −
| All Testing Phases | % of Effort |
|---|---|
| Component Testing | 16 |
| Independent Testing | 84 |
| Total | 100 |
| Independent Testing | % of Effort |
|---|---|
| Integration Testing | 24 |
| System Testing | 52 |
| Acceptance Testing | 24 |
| Total | 100 |
| System Testing | % of Effort |
|---|---|
| Functional System Testing | 65 |
| Non-functional System Testing | 35 |
| Total | 100 |
| Test Planning and Design Architecture | 50% |
| Review phase | 50% |
Experience-based Testing Estimation Technique
This technique is based on analogies and experts. The technique assumes that you already tested similar applications 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 application (as well as testing) very well and use the metrics you have collected and arrive at the testing effort.
”;