In our last discussion, we pulled back the curtain on the factors that influence test effort—the “what” that goes into our calculations. We talked about everything from the size and complexity of the product to the skills of our team. Today, I want to move from the “what” to the “how.” How do we actually take all that information and forge it into a reliable estimate? The answer lies in choosing the right test estimation technique.
Think of these techniques as different tools in a toolbox. You wouldn’t use a sledgehammer to hang a picture frame, and you wouldn’t use a tiny screwdriver to break up concrete. Similarly, the method we use to estimate testing for a small, simple project will be very different from the one we use for a massive, complex enterprise system.
The goal is always the same: to produce an estimate for the cost, effort, and duration of testing that is both realistic and justifiable. This estimate has to be delivered to project management with a clear explanation of how we got there. It’s a living document—a snapshot based on the information we have at the time. As the project evolves and new information comes to light, we must revisit and refine our estimates to keep them accurate.
So, how do we pick the right tool for the job? Let’s explore the main approaches and the criteria we use to select the perfect fit for any given project.
The Two Main Schools of Thought: Metrics vs. Experts
At a high level, nearly all test estimation techniques fall into one of two major categories: they are either based on hard data or on human experience.
Metric-Based Techniques: The “Show Me the Data” Approach
This family of techniques is analytical and quantitative. It relies on using metrics, often from past projects, to calculate an estimate for the current one. It’s the “by the numbers” approach to estimation. If you have solid historical data from similar projects, this method can be incredibly powerful and objective.
Examples include:
- Ratio-Based Estimation: We look at data from a previous project and establish a ratio. For instance, we might find that it took, on average, three hours of testing per requirement, or that we wrote five test cases for every function point. We can then apply that ratio to the current project’s scope to get a baseline estimate.
- Extrapolation: This involves using data from past or current projects to predict a trend. For example, by tracking the number of defects found per week in the early stages of a project, we can extrapolate a curve to predict how many more we are likely to find and how long it might take for that number to stabilize.
The major strength of metric-based techniques is their objectivity. The estimate is derived from a formula, making it easy to explain and justify. However, their great weakness is their complete dependence on the availability and relevance of historical data. If you don’t have data, or if the data you have is from a wildly different type of project, this approach can be misleading.
Explore our guide about test metrics: Measuring What Matters: A Practical Guide to Test Metrics
Expert-Based Techniques: The “Ask the People Who Know” Approach
This family of techniques is qualitative and collaborative. It relies on the intuition, judgment, and experience of subject matter experts—usually the very people who will be doing the work. This approach is invaluable when you’re facing something new, complex, or highly uncertain, and historical data is either non-existent or irrelevant.
Examples include:
- Planning Poker: A cornerstone of Agile development, this technique involves the entire team. Team members use numbered cards to vote on the “size” or “effort” of a task (like a user story). This sparks a discussion where team members share their reasoning, leading to a shared understanding and a consensus-based estimate.
- Wideband Delphi: This is a more formal consensus-building technique. A group of experts provides anonymous estimates for a task. A facilitator averages the results and shares them with the group, who then discuss the outliers and re-estimate. This process is repeated for a few rounds until the estimates converge, helping to eliminate the influence of “groupthink” and dominant personalities.
The strength of expert-based techniques is their adaptability. They harness the collective wisdom of the team to tackle uncertainty. The potential weakness is subjectivity; the estimate is only as good as the experts providing it.
Read our guide to set up a stakeholder matrix effectively here: Who’s in Your Corner? A Developer’s Guide to the Stakeholder Matrix
Choosing Your Weapon: Factors That Guide Your Selection
Now that we know the two main families, how do we choose a specific technique? The selection is a strategic decision that depends on several critical factors related to our project’s context.
1. How Much Wiggle Room Do We Need? (Estimation Error)
Any estimate is a prediction, and predictions come with a degree of uncertainty. Some techniques, however, allow us to quantify that uncertainty, which is incredibly useful when communicating with stakeholders.
A fantastic example of this is the Three-Point Estimation technique. Instead of asking for a single number, we ask for three:
- An Optimistic Estimate (O): The best-case scenario, if everything goes perfectly.
- A Pessimistic Estimate (P): The worst-case scenario, if everything that can go wrong does go wrong.
- The Most Likely Estimate (M): The most realistic guess based on experience.
With these three numbers, we can use simple formulas to calculate not just an Expected Value (E) but also a Standard Deviation (σ). The expected value gives us our working estimate, and the standard deviation tells us how much variability or risk is associated with it. For example, the formula for the expected value is often E=(O+4M+P)/6, which gives more weight to the most likely scenario.
Presenting an estimate as a range (e.g., “We estimate this will take 100 hours, with a standard deviation of 15 hours”) is much more powerful than a single number. It communicates confidence levels and helps stakeholders understand the potential risks upfront.
Refer to our guide about test estimation here: More Than a Guess: A Guide to Practical Test Estimation
2. Do We Have a Rear-View Mirror? (Data Availability)
This is perhaps the most practical selection criterion. Does your organization have a repository of data from previous projects? Is it reliable? Is it relevant?
If the answer is a resounding “yes,” then metric-based techniques like ratio analysis or extrapolation become very attractive. If your team has just completed three similar mobile app projects, using the data from those projects to estimate a fourth is a logical and data-driven approach.
However, if you’re building a first-of-its-kind virtual reality application and your company has only ever built web portals, that historical data is useless. In this case, relying on metric-based estimation would be irresponsible. The lack of relevant data immediately pushes you towards expert-based techniques, where you rely on the judgment of your team to navigate the new territory.
Make use of the AgileTest custom dashboard feature that helps you manage your data effectively
3. Who’s in the Room? (Expert Availability)
Some of the most effective techniques are entirely dependent on having access to the right people. You simply cannot use an expert-based technique without available experts.
Planning Poker is the perfect example. Its success hinges on having the project team—developers, testers, product owners, and scrum masters—together in a room (physical or virtual). It’s the collective knowledge of this cross-functional group that makes the estimates meaningful. If your key experts are unavailable or you can’t get the team together, this technique falls flat.
Similarly, the Delphi method requires a panel of identified experts. If you can’t assemble a group with the necessary knowledge and experience in the subject matter, the technique is not viable. Therefore, the availability and engagement of your people are a primary filter for selecting your estimation approach.
4. Are We Mathematicians or Testers? (Knowledge in Modeling)
Let’s be honest: some techniques require more comfort with mathematics than others. While most testers are analytically minded, not everyone wants to be building complex statistical models.
Techniques like three-point estimation or extrapolation require applying specific formulas. They aren’t advanced calculus, but they do require a level of skill and knowledge in modeling to be applied correctly. If the team isn’t comfortable with the math behind a model, they are less likely to trust the results, and the estimation exercise becomes a black box.
In contrast, techniques like Planning Poker or simple ratio-based estimation are mathematically very straightforward. The choice here is about pragmatism. We should select a technique that the team understands, trusts, and can apply confidently. The goal is a credible estimate, not a demonstration of our mathematical prowess.
5. How Much Time Do We Have… to Estimate Time? (Time Constraints)
This factor can feel a bit meta, but it’s a real-world constraint. The process of creating an estimate takes time and effort itself, and some techniques are much more time-consuming than others.
Planning Poker, for instance, is designed to be a relatively quick, iterative process that fits neatly into an Agile sprint planning ceremony. It’s fast and efficient. On the other end of the spectrum, conducting a full Wideband Delphi estimation can be a lengthy process involving multiple rounds of anonymous input, data consolidation, and group discussion over several days.
The choice depends on the project’s needs. If we’re in an Agile sprint and need a quick estimate for a handful of stories, Planning Poker is perfect. If we are at the very beginning of a year-long Waterfall project and need to produce a highly detailed, defensible budget estimate for senior management, the more time-intensive and rigorous Delphi method may be the more appropriate, and necessary, investment.
Context is King: Matching the Technique to the Project
Ultimately, the selection of a test estimation technique is highly dependent on the project’s context. There is no single “best” technique. As a Test Manager, a key part of my job is to analyze the context and choose the most suitable approach—and sometimes, it means using different approaches for different parts of the same project, especially in a large organization with multiple teams or subsidiaries.
Here are some practical rules of thumb that I follow:
- Based on Complexity: If the work is well-defined, simple, and has been done before, I lean towards metric-based techniques. The data provides a reliable foundation. If the work is new, complex, uncertain, or high-risk, I lean heavily on expert-based techniques. Human judgment is best for navigating the unknown.
- Based on Development Model (SDLC): This is often the most important deciding factor.
- For an Agile project, the natural fit is an iterative, collaborative, expert-based technique. Planning Poker is the industry standard for a reason. It aligns perfectly with the Agile philosophy of empowering the team and embracing change.
- For a sequential (Waterfall) project, you typically need a comprehensive, detailed estimate upfront. This is where a more formal technique like Wideband Delphi shines. It provides a structured and well-documented estimate that can be used for initial project planning and budgeting.
Install AgileTest to manage your test project efficiently.
Conclusion
Choosing a test estimation technique is far from an arbitrary decision. It’s a strategic choice that directly impacts the credibility and accuracy of your entire test plan. By carefully considering the factors—the need to quantify error, the availability of data and experts, the team’s skills, and the time constraints—we can select the right tool for our specific context.
When we present our estimate to management, the technique we used is a core part of our justification. It allows us to explain how we arrived at our numbers. This transforms the conversation from a potentially adversarial negotiation into a collaborative planning session. It moves us away from “Why does testing need so much time?” and towards “Thank you, I understand what it will take to achieve our quality goals.” By making a thoughtful choice, you’re not just predicting the future; you’re building a credible and transparent roadmap for success.
