Software Testing Estimation

Software testing effort estimation is a skill required of a Test Lead or a Test Manager. However, test effort estimation is not a skill that one can learn quickly. It requires understanding of several key concepts and practice.  In the previous post on estimation techniques, we have seen six approaches to get software test effort estimates. In this post, we will look at one possible software testing estimation formula. Before using it, you need to customize it according to your test process. This formula is explained with an example in my video on Test Estimation with formula example.

Software Testing Estimation Formula

Task	Usage notes	Cumulative Effort Estimate(hours)
QA/test environment preparation	Estimate this based on hardware installation, software installation and deployment of builds as T1	T1
Testing of n requirements	Estimate testing time per requirement, T2, based on the detail of requirements e.g. T2 can be 0.5 if requirements are detailed or up to 4 if the requirements are high level.	T1 + T2 * n
Negative and exploratory testing	Use, say, 40% extra testing time per requirement, to cover the paths other than the “happy path”, and exceptional and invalid test data inputs.	T1 + T2 * n * 1.4
Re-testing due to requirement correction or changes	Estimate factor T3, based on requirement correctness and stability e.g. T3 can be 0.1 if requirements are well put and stable or 0.5 if requirements have multiple issues or are very dynamic. Let us use T3 as 0.2.	T1 + T2 * n * 1.6
Logging defects and re-testing fixes	Estimate the number of defects as T4. Estimate time to log defect, say 0.25 and time to re-test a fix, say 0.25	T1 + T2 * n * 1.6 + T4 * 0.25 + T4 * 0.25
Regression testing	Estimate this effort based on the impact of requirements implemented, defects and depth needed as T5.	T1 + T2 * n * 1.6 + T4 * 0.5 + T5
Reserve	Having this reserve helps to provide time to complete unforeseen tasks. Estimate the reserve as T6 between 5 and 10% of overall effort	(T1 + T2 * n * 1.6 + T4 * 0.5 + T5) * (1 + T6)
Communication	Estimate the daily effort in hours on meetings and reporting as T7. Multiply it by team members T8 and number of testing days T9.	(T1 + T2 * n * 1.6 + T4* 0.5 + T5) * (1 + T6) + T7 * T8 *T9

Now let us see an example. Assuming the following:
Test environment preparation time, T1 = 2 hours
Number of requirements, n = 100
Time to test each requirement, T2 = 0.5 hours
Number of defects, T4 = 10
Regression testing time, T5 = 8 hours
Reserve, T6 = 5% i.e. 0.05
Daily time spent on meetings and reporting, T7 = 0.5 hours
Number of testers, T8 = 2
Number of testing days, T9 = 5
(T1 + T2 * n * 1.6 + T4* 0.5 + T5) * (1 + T6) + T7 * T8 *T9 becomes
(2 + 0.5 * 100 * 1.6 + 10* 0.5 + 8) * (1 + 0.05) + 0.5 * 2 *5 = 104.75 hours
This time includes the time to set up the test environment, positive/ negative/ exploratory testing of requirements, re-testing requirement clarifications/ changes, logging defects and re-testing fixes, regression testing, meetings and reporting.

There are several ways to confirm your software testing effort estimate.  Use your judgment to find if it looks too low, right or too high. Compare it with the actual testing efforts data for previous projects. Find out if it is 25% - 30% of development effort (do not know why but I have noticed that this range seems acceptable to project managers). You can also ask other managers to review your estimate. Once you have arrived at the test effort estimate for your project and have convinced the stakeholders that it is a reasonable estimate, track the actual progress in your project constantly to see if it is in line with your estimate.

Significant deviation from software testing effort estimate may have financial implications. If you end up charging for more testing effort, the client would not be happy. Alternatively, if it a fixed-price project, you company would not be happy with reduced profitability that comes with higher actual effort. Realistic estimation is important to pay attention to coming up with the suitable formula, estimate the factors realistically and confirm your estimate by using alternative approaches.