Tech Insights

Why Test Estimation Techniques in Software Testing Are Worth The Effort

Estimating testing time delivers quality software. Software testing makes sure your software works as it should. But how do teams figure out how much time and effort testing will take? Accurate estimation techniques help teams plan better, avoid delays, and, ultimately, do a better job. Here we take a closer look at some of these techniques and how teams can plan better and get their software out the door faster.  

What Is Test Estimation? 

Simply put, test estimation in software testing is a management activity that helps us find out how long it will take to test our product and how much that testing will cost.

What can be estimated? Basically, everything that can be quantified, like money, resources, or time.

QA Estimation Techniques

We’ll cover the most effective test estimation techniques that yield the best results.

1. Decomposition (Work Breakdown Structure)

This test estimation method is straightforward and practical. The main concept is to break down your work into smaller, more manageable segments.

For instance, consider a large story outlining login functionality, covering aspects like user permissions, invalid credentials, and locked accounts. We can divide this into four distinct parts: page view verification, login with valid credentials, login with invalid credentials, and login with a locked account.

Once we’ve identified these task segments, we can estimate the required labor-hours for testing each one. We then sum these estimates to determine the total time needed.

If an initial estimate isn’t possible, we refine the decomposition further. We continue to break down the tasks into more detailed steps until each action becomes a single, manageable task. Using the previous example as a guide:

Page view check

  • Check header
  • Check footer
  • Check page elements

Login with valid credentials

  • Login with valid email and valid password
  • Login as different users
  • Login with admin permissions

Login with invalid credentials

  • Login with invalid email and invalid password
  • Login with valid email and invalid password
  • Login with invalid email and valid password

Login with a locked account

  • Login with a locked account
  • Login with an unlocked account that was locked again

Next we’ll estimate each step in man-hours:

Name of functionality  Estimates, mh (man-hours)
1. Page view check = 0.3 
1.1 Check header 0.1
1.2 Check footer 0.1
1.3 Check page elements 0.1
2. Login with valid credentials  = 0.38 
2.1 Login with valid email and valid password 0.15
2.2 Login as different users 0.1
2.3 Login with admin permissions 0.13
3. Login with invalid credentials = 0.45
3.1 Login with invalid email and invalid password 0.15
3.2 Login with valid email and invalid password 0.15
3.3 Login with invalid email and valid password 0.15
4. Login with a locked account  = 0.45
4.1 Login with a locked account 0.15
4.2 Login with an unlocked account that was locked again 0.3
Total = 1.58 mh

The final test estimation is then the sum of all the scenarios: 0.3 + 0.38 + 0.45 + 0.45 = 1.58 labor-hours. This is just an example of how to calculate estimations.

**Remember to factor in risks specific to your project when making your estimates.

2. Test case-based estimates

The second QA estimation method bears similarities to the decomposition approach but differs in certain aspects.

For this technique, you need to create test cases for the task that you need to estimate, then assign a value for each test case (e.g., 0.1 labor- hours). Then, add up all the values and get the total estimate.

For instance, you need to execute 320 tests for regression testing. If you do not have the exact metrics on the test, then you can put 0.1 labor-hour per test case, which would be a total of 0.1 mh x 320 = 32 mh.

**Remember to factor in risks specific to your project when making your estimations.

3. Three-points estimation

This is one of the easiest QA estimation techniques. It relies on deriving an average from three distinct scenarios:

The best case: the optimistic scenario. In this case, you have a skilled team and all the necessary resources to complete the task. For instance, let’s imagine the task could be completed in 50 labor-hours under these ideal conditions.

The most likely case: the normal scenario. Your team is competent, things mostly go as planned, with some minor issues that are resolved. In this scenario, the estimated time might be 100 labor-hours.

The worst case: the pessimistic scenario. The team is not experienced enough (needs additional training and exercise), everything goes wrong, and the team has to solve numerous problems (e.g. restricted access to test environments, environmental issues, delays in receiving requirements, etc.). In this hypothetical situation, the estimate would be 150 labor-hours.

There are two commonly used formulas for calculating this estimation. The first one is:

Triangular Distribution: Estimate = (optimistic + normal + pessimistic )/3

The second one is part of the PERT method.

4. PERT (Program Evaluation and Review Technique)

The Program Evaluation Review Technique (PERT) is a test estimation method initially developed by the United States Department of Defense for its ballistic missile development program. It was vital that this program be completely fast, to outpace other nations; however, it was also fraught with uncertainty due to the involvement of numerous supplier agencies developing new technologies. The PERT estimation method enabled them to factor these uncertainties into their estimates, allowing them to finish the program ahead of schedule.

PERT employs a three-point estimation approach for tasks: optimistic, normal, and pessimistic. Unlike the conventional three-point estimation formula, the PERT formula places greater emphasis on the ‘normal’ scenario.

Estimation = (optimistic + 4*normal + pessimistic)/6

Best Practices and Tips

Here are a few QA best practices and tips to help you with your estimations:

  1. Keep your cool and stay unbiased

    Keep in mind that when you’re estimating tests, it’s for your team’s benefit. If you’re not objective, it could result in extra hours, compromised work quality, and potentially harm your reputation. Incorrectly gauging your team’s experience level could also cause missed deadlines.

  2. Don’t wear out your team

    Don’t underestimate the project’s scope just to set a target and then pressure your team to meet it. While they might deliver what’s needed, this approach could drive them to look for opportunities elsewhere that offer a more reasonable workload and better work-life balance.

  3. Weigh the odds

    Consider all the risks. Unexpected situations can pop up that we can’t control. It’s a good idea to anticipate these and factor in extra time or resources to handle them.

  4. Trust your experience

    Drawing on lessons from past projects can be incredibly valuable and can save us a lot of time. The same applies to tapping into our team’s previous knowledge and skills. It’s like having a playbook to help us avoid repeating mistakes or reinventing the wheel.

  5. Don’t be shy to ask for help

    If you’re not sure how to approach an estimation activity, ask an expert. You will get a helpful overview of the situation and gain new skills.

Understanding the importance of test estimation techniques in software testing saves time and money. Test estimation methods are expected to evolve in response to technological advances and industry trends. This will likely lead to more dynamic and data-driven estimation techniques. With 88% of organizations adopting agile practices, there’s a clear need for agile-centric estimation methods tailored to rapid development cycles.

Author: Karolina Panada