A Quick Synopsis on Software Test Estimation
Software Test Estimation is a crucial management activity in the Software Development Life Cycle (SDLC). It plays a key role in the success of a project by ensuring proper execution of tasks.
Prior to the estimation, you need to ask a couple of questions to yourself as below.
• What will be the different tasks that need to be performed?
• How much effort would each task take? (or effort estimation)
You will move forward with a particular approach based on the available data and the time in hand to generate the estimates.
Some of the common effort estimation approaches take into account the software size, the WBS (Work-Breakdown Structure), project history data( if available), company’s estimation software and estimation models. If the above data is not available, then we could use expert judgement as well. It is better to use multiple approaches to find out the exact effort.
If the test effort estimates are needed quickly, then we can prefer estimating activities at a summary/group level. Then we can use another estimation approach to know if the estimates seems satisfactory.
A Sample Test Estimation using WBS
You will find a sample test estimation using the technique Work-Breakdown Structure (WBS) below. This approach is used mostly for bigger projects. In this, a project is divided into smaller tasks before proceeding to do the estimation.
| Task | Notes | Cumulative effort | Cumulative effort in hours |
| QA environment or Test environment preparation | Estimate this based on hardware installation, software installation and deployment of builds as T1, say 2 hours. | T1 | 2 |
| Testing of n requirements | Estimate testing time as per requirement (this approach is used if the requirement are given), T2. Say there are 50 requirements and each testing time is 0.5 hour. | T1+ T2*n | 27 |
| Negative and exploratory testing | Use 20% extra testing time per requirement | T1+ T2*n*1.2 | 32 |
| Retesting due to requirement correction or changes | Estimate factor T3, based on requirement correctness and stability. eg. 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.4 | 37 |
| 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. Say 10 defects | T1+ T2*n*1.4+T4*.25+T4*0.25 | 52 |
| Regression testing | Estimate this effort based on the impact of the requirements implemented. Defect and depth needed as T5, say 5 hours | T1+ T2*n*1.4+T4*.25+T4*0.25+T5 | 57 |
| Reserve | Having this reserve helps to provide time to complete unforeseen tasks, Estimate the reserve as T6 between 5 and 10 % of overall effort, say 5% | T1+ T2*n*1.4+T4*.25+T4*0.25+T5 + T6 | 60 |
| Communication | Estimate the daily effort in hours on meetings and reporting as T7,say 0.5, Multiply it by team members T8 say 2 and number of testing days T9 days 4 | T1+ T2*n*1.4+T4*.25+T4*0.25+T5 + T6 + (T7*T8*T9) | 64 |
Other Estimation Techniques
A. Delphie Method
This method is based on surveys. It basically collects the information from participants who are experts. The moderator makes a team of knowledgeable persons who will be assigned the task of estimating a requirement. Every estimation will be collected by the moderator itself, then he/she compares the result. If any diverging estimation is found, he/she calls for another round and estimation will be done (only for diverging estimation). This process will be repeated until the estimation is within an acceptable range.
B. Three Point Estimation Method
This estimation method is similar to WBS. In this, tasks are broken down into subtasks and three types of estimations are done into sub pieces.
To calculate an estimation for a task called “Test Case Preparation”, use the below formula:
E= (a+4m+b)/6
a = best case to complete the task
m = Most likely case to complete the task
b = Worst case to complete the task
E= Weighted average
The next step is to find the probability that the estimation is correct. To get this, use the below formula:
SD = (b-a)/6
SD = Standard Deviation
So to complete the task “Test Case Preparation” you may need E ± SD man hours.
Risks with Test Estimation
Below are a few risks associated with Test Estimation:
• Missing of important details due to hidden factors.
• Over or underestimations
• It is based on thinking
• Resource risks
• Technical risks
Should we revise the test effort estimates?
We must revise the estimates whenever there are material changes in the project. For example: new features added to the system under test, new types of testing like load testing is needed and resource changes.
We can also improve our test estimation by comparing the actual effort data at the end of the project.
Conclusion
There are a lot of estimation techniques available other than mentioned here, like Functional Point (Estimating by analyzing the complexity of functionalities), Use Case Point Method (based on the use cases) and Expert Judgements. If your organization has its own process for estimation, it is always better to compare your estimation hours with two or three other estimation techniques. This helps us to have a clear idea about how effective is our estimation.
About Robin Babu
Robin is a B-Tech Computer Science Graduate and an ISTQB-certified professional with four plus years of experience in QA testing.
View all posts by Robin Babu →
Wow, what an informative blog. Helped me a lot.