5.2 Test Estimation and Prioritization
Key Takeaways
- Test estimation predicts the work needed to meet test objectives and should state its assumptions and uncertainty.
- Large testing tasks are usually estimated better after decomposition into smaller tasks.
- Ratio-based and extrapolation techniques use metrics, while Wideband Delphi, Planning Poker, and three-point estimation use expert judgment.
- Test case prioritization may be risk-based, coverage-based, additional-coverage-based, or requirements-based.
- Dependencies and resource availability can override a simple priority order.
Estimating Test Effort
Test effort estimation predicts how much work is needed to meet the test objectives. The estimate may be expressed in hours, person-days, story points, team capacity, calendar duration, or cost. A good estimate is not just a number. It also states assumptions, constraints, confidence, and what is excluded.
Estimation is easier for small tasks than large tasks. "Test the checkout service" is too broad. Better tasks include review acceptance criteria, design boundary tests for discounts, prepare payment test data, execute happy-path and negative tests, run regression tests, and retest fixed defects. Decomposition makes hidden work visible.
Four CTFL Estimation Techniques
| Technique | Type | Main idea |
|---|---|---|
| Estimation based on ratios | Metrics-based | Use historical ratios, such as development effort to test effort |
| Extrapolation | Metrics-based | Use early current-project measurements to forecast remaining effort |
| Wideband Delphi | Expert-based | Experts estimate independently, discuss outliers, and repeat to consensus |
| Three-point estimation | Expert-based | Combine optimistic, most likely, and pessimistic estimates |
Ratio-based estimation works best when the organization has reliable historical data from similar projects. If past teams usually spent 2 test days for every 3 development days, 600 development days may suggest about 400 test days. The trap is assuming the ratio applies when the product, team, risk, tools, or quality expectations have changed.
Extrapolation is useful in iterative development. If the last three iterations required 45, 50, and 55 hours of test work for comparable story volume, a team may forecast about 50 hours for the next similar iteration. The estimate becomes weaker when the next iteration contains unusual risks, new technology, or dependencies not present in the measured iterations.
Wideband Delphi is structured expert estimation. Experts estimate independently first so one loud voice does not anchor the group. Then the group discusses large differences, clarifies assumptions, and estimates again. Planning Poker is a common Agile variant. The value is not only the final number; it is the shared understanding created by discussing uncertainty.
Three-point estimation uses an optimistic value (a), most likely value (m), and pessimistic value (b). A common weighted formula is E = (a + 4m + b) / 6. If a task has a = 6, m = 9, and b = 18 hours, the estimate is 10 hours. The standard deviation is often shown as SD = (b - a) / 6, so this example has SD = 2 hours.
Prioritizing Test Cases
After test cases and test procedures are ready, they must be ordered for execution. Prioritization helps find important failures earlier and gives stakeholders useful information sooner. This matters when time is limited, builds are unstable, environments are shared, or defects block later testing.
Risk-based prioritization runs tests covering the most important risks first. A payment authorization path with high business impact and high likelihood of failure should run before a low-impact cosmetic preference. This approach is central to risk-based testing because it connects test order to product risk.
Coverage-based prioritization executes tests that achieve the highest coverage first. Coverage might mean statement coverage, branch coverage, requirements coverage, interface coverage, or another agreed measure. Additional coverage prioritization chooses the first test with high coverage, then each next test that adds the most new coverage not already achieved.
Requirements-based prioritization follows stakeholder priority. If a business marks legal consent capture as mandatory and profile image cropping as low priority, related tests should reflect that priority. This approach is helpful when business value, regulation, or contractual obligations drive release decisions.
Dependencies and Resource Limits
Priority is not the only input to execution order. A high-priority refund test may require a completed purchase test first. A performance suite may need a load test environment available only overnight. A security specialist may be available for one day. In those cases, the realistic schedule must balance priority, dependency, and resources.
The exam often presents attractive but incomplete choices. "Always execute highest priority first" sounds right, but dependencies can make it impossible. "Always automate first" is also too broad. The CTFL answer usually considers risk, coverage, requirements, dependency, resources, and the objective of getting useful feedback early.
Experts estimate a testing task as 4 hours optimistic, 7 hours most likely, and 16 hours pessimistic. Using E = (a + 4m + b) / 6, what is the estimate?
Which factors can legitimately affect test execution order?
Select all that apply