Software Testing Effort Estimating

Traditional Practices

1.    Current Test Planning Methods include
a.    Using Percentage of Development Effort
i.    Depends on the accuracy of the Development Effort
ii.    Does not account revisit of Development Effort
b.    Using Tester Developer Ratio
i.    May not be same for all types of Projects
ii.    Does not consider the size of the Project
c.    Using KLOC
i.    Does not consider Complexity, Criticality & Priority of the Project.

What’s the Best Approach to Test Estimation?

There is no simple answer for this. The 'best approach' is highly dependent on the particular organization and project and the experience of the personnel involved.

For example, given two software projects of similar complexity and size, the appropriate test effort for one project might be very large if it was for life-critical medical equipment software, but might be much smaller for the other project if it was for a low-cost computer game. A test estimation approach that only considered size and complexity might be appropriate for one project but not for the other.

Approaches to Test Estimation

1. Implicit Risk Context Approach:

2. Metrics-Based Approach:

3. Test Work Breakdown Approach:

4. Iterative Approach:

5. Percentage-of-Development Approach:

   Test Estimation Process – A Practical Approach

1.    Combination of all the Approaches
2.    Considers Risk & Complexity Factors
3.    Based on Previous History i.e. Organization or Project Metrics
4.    Based on Work Breakdown Structure
5.    Based on Iterative Model

Elements of Test Estimation Process 

1.    Break sizing into smaller, easier to estimate tasks
a.    Decompose the test project into phases:

i.    System Test

ii.    Unit Test

b.    Decompose each phase into constituent activities:

i.    System Test Planning

ii.    Test Execution


c.    Decompose each activity into tasks and subtasks until each task or subtask at the lowest level of composition:


i.    Executing a test scenario
ii.    Writing a defect


2.    Taking risk priority into account
3.    Set up dependencies
a.    Dependent tasks internal to the test subproject.
b.    Document dependencies, resources, and tasks external to the test subproject (i.e., those that involve collaborative processes)
• Consider type of code (complex, reused, etc.)
• Augment professional judgment and gut instinct with previous project data, industry metrics, and so forth.
• Identify and, if possible, resolve discrepancies between the test subproject schedule and the project schedule.
• Use the work-breakdown-structure and schedule to develop a budget. Extract from your work-breakdown-structure a complete list of resources. For each resource, determine the first and last day of assignment to the project.
• If you have resources shared across multiple test projects within a given time period, understand the percentage allocation of each resource’s assignment to each project during various time periods.
• Revisit the Estimation continuously in order to reflect any change in the Project Requirements or Schedule
• Be Repeatable preferably Automat able

A Sample Estimation Process 

Total work = Test case time + Defect time
Test Case Time = Test Case Development time + Test Case Execution Time
Defect Time = (Hours/Defect * # Defects)

Note:  Consider the defect severities while arriving at Hours/Defect and also that Hours/Defect should take into account the Defect creation time, Debugging time and Defect Retesting time till the closure.

Test Case Time 

Test Case Development Time = (Hours/Test case development* #Test cases)
Test Case Execution Time = (Hours/Test case Execution  * #Test Cases)

Note:  Consider the Risk, Complexity while arriving at the Hours/Test case Development and Hours/Test case Execution.

Previous Test Estimation and Planning Topics:

1. Complete Tutorial on Test Plan

2. What is Traceability Matrix from Software Testing perspective?

3. Software Testing Strategy and Methodology

4. Plan Your Software Testing Activities