Test Effort Estimation

Challenges

Successful test effort estimation is a challenge because

• No standard Formulae/Methods for Test Estimation
• Test Effort Estimates also includes the Debugging Effort
• Difficult to attempt testing estimates without first having detailed information about a project
• Software Testing Myth that Testing can be performed at the End
• Difficult to attempt testing estimates without an understanding of what should be included in a ‘testing’ estimation for a project (functional testing? unit testing? reviews? inspections? load testing? security testing?)

Traditional Practices

Current Test Planning Methods include using Percentage of Development Effort. It has a number of drawbacks like
it depends on the accuracy of the Development Effort and does not account revisit of Development Effort. Using Tester Developer Ratio may not be same for all types of Projects. Where as using KLOC does not consider Complexity, Critical & Priority of the Project.

What is the best approach to test effort 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.

Different approaches to test estimation are as follows:

1. Implicit Risk Context Approach
2. Metrics-Based Approach
3. Test Work Breakdown Approach
4. Iterative Approach
5. Percentage-of-Development Approach

 Elements of Test Estimation Process

• Breaking and sizing into smaller, easier to estimate tasks

1. Decompose the test project into phases viz. Unit testing, Integration testing, System Testing, Acceptance testing etc.
2. Decompose each phase into constituent activities – System test planing, test case writing, test case execution etc.
3. Decompose each activity into tasks and sub-tasks until each task or sub-task at the lowest level of composition. Like executing a test scenario, defect reporting etc.

• Taking Risk priority into account

• Taking dependencies into account

1. Dependencies internal to the test sub-project between tasks.
2. Document dependencies, resources, and tasks external to the test sub-project. Third party dependencies.

• Miscellaneous

1. Consider type of code (complex, reused, etc.)
2. Augment professional judgment and gut instinct with previous project data, industry metrics, and so forth. 
3. Revisit the Estimation continuously in order to reflect any change in the Project Requirements or Schedule.