Test estimation in software testing is a sensitive issue. On the one hand, stakeholders want/need to know how much time, effort and resources will be required to plan their software projects.
Many thought leaders in the software testing industry will eloquently argue that test estimation is 1) impossible, and 2) a bad idea.
Leaving that conversation aside for now, let’s focus on the stakeholder’s need to have some sense of scope to adequately plan their projects and what is possible to do to achieve that.
What is test estimation?
Test estimation is the process of gathering all the available data, weighing the key factors involved and predicting what the costs of testing a particular program will be. Costs are usually measured in terms of time, resources and/or money.
Major factors to consider in test estimation
- The size abd complexity of the system being tested
- The types of tests required
- The frequency of releases made by the development team
- Whether or not the program requirements have been finalized
- The product’s key risks and their severity
- The skill and experience of the testing team
- The availability of testing resources
- The readiness and availability of the test environment
Common approaches to test estimation
Test estimation is widely considered to be part science, part art; therefore, it should come as no surprise to learn that there are a wide variety of approaches, each with their own strengths and weaknesses. Here we will look at 3 of the most commonly used techniques.
Work Breakdown Structure (WBS)
This approach involves breaking down the overall testing task into a hierarchy of individual components, which are then broken down further and further according to their functionalities. The beauty of this approach is that it focuses on the finer details, making it less likely that anything major will be missed, and in doing so fosters a sense of commitment and accountability within the testing team.
Three Point Estimation
Similar to the WBS technique, this approach involves breaking down larger tasks into smaller sub-sections, but unlike WBS the Three Point Estimation method is based on statistical data. Once tasks have been broken down, values are allocated to each one for three different scenarios; the most optimistic (A), the most likely (M) and the most pessimistic (B). The following formula is then used to calculate an estimate value;
Value of estimate (E) = (A + 4M + B)/6
The Delphi Technique
This approach requires the participation of multiple experts. Each expert prepares their own estimate before gathering with the group, discussing their findings and together coming up with a ‘best’ estimate. The benefit of this system is that it considers multiple points of view, that can not only lead to a more accurate estimate but also greater insight into the product under test.
Keep in mind that none of these methods are perfect and accurate test estimations are unheard of in our industry.
These 3 methods are a good way to have a sense of scope, but independently of whether you conduct your software testing activities in-house, you outsource them or crowdsource them, there’s no such thing as too much testing!