Test Estimation is a management activity which approximates how long a Task would take to complete. Estimating effort for the test is one of the major and important tasks in Test Management.

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

• Resources: Resources are required to carry out any project tasks. They can be people, equipment, facilities, funding, or anything else capable of definition required for the completion of a project activity.
• Times : Time is the most valuable resource in a project. Every project has a deadline to delivery.
• Human Skills : Human skills mean the knowledge and the experience of the Team members. They affect to your estimation. For example, a team, whose members have low testing skills, will take more time to finish the project than the one which has high testing skills.
• Cost: Cost is the project budget. Generally speaking, it means how much money it takes to finish the project.

How to estimate?

List of Software Test Estimation Techniques

• Work Breakdown Structure (Decomposition )
• Test case based estimates
• 3-Point Testing Estimation
• PERT (Program Evaluation and Review Technique)

1. Decomposition (Work Breakdown Structure)

This test estimation technique is the simplest and easiest to apply. The key idea is to split your work into smaller manageable chunks, as much as possible.

Let’s say you have a huge story that describes login functionality: login for users with permissions and without permissions, login with invalid credentials, locked users, etc.

We will now split this scenario into 4 logical parts: page view check, login with valid credentials, login with invalid credentials, login with a locked account.

Once we’ve separated the parts of the task, if we can estimate it already, we can set a man-hour value necessary for testing of each part, and then sum it all up to get a full time estimate.

And if we can’t estimate it yet? Decompose more. To do this, we’ll split the tasks into smaller details until one step is equal to one action. To continue the example above:

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 man-hours. It is just an example of how to calculate estimations.

** don’t forget that risks need to be included into your estimations on your project specifics

2. Test case based estimates

The second QA estimation technique is similar to the decomposition method, but has a few key differences.

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 man-hour). Then, add up all the values and get the total estimate.

For example, 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 man-hour per test case, which would be a total of 0,1 mh x 320 = 32 mh.

** don’t forget that risks need to be included into your estimations on your project specifics

3. Three-points estimation

This is one of the easiest QA estimation techniques. In this technique, you end up with an average number that is derived from three different scenarios:

The best case: the optimistic scenario. In this case, you have a skilled team and everything else that is needed to complete the task. As a hypothetical, let’s say you can complete the task in 50 man-hours in this scenario.

The most likely case: the normal scenario. Your team is skilled enough; almost everything goes as expected; issues occur, but get solved. To continue the hypothetical, this scenario gives us an estimate of 100 man-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. no access for test environment, environmental issues, delay with requirements delivering, etc.). In this hypothetical situation, the estimate would be 150 man-hours.

There are two popular formulas to calculate the estimation, here’s the 1st one:

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

The 2nd one is part of the PERT method.

4. PERT (Program Evaluation and Review Technique)

Program Evaluation Review Technique is a test estimation technique, which was first developed and applied by the United States Department of Defense for its ballistic missile development program. This program was both critical to complete on time, ahead of other nations, but also filled with a huge amount of uncertainty, as it required a large number of supplier agencies working on new technology development. The PERT method of estimation helped them build all of the uncertainties into their estimates and complete the program ahead of their expected schedule.

PERT uses a three-point estimation approach for a task: optimistic, normal, and pessimistic.

Unlike the above three-point estimation formula, the PERT formula gives more weight to the possibility of ‘normal’ scenario. 

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

Best Practices and Tips

Here are a few QA best practices tips to help you in your estimation activities:

1. Stay objective. Remember that you’re doing this test estimation for yourself and your team.  If you aren’t objective, it may lead to unfavorable outcomes like unpaid overtime, or a lower quality of work (which might affect your reputation). Thus, the wrong estimation of a team level of experience, may lead to missing the deadline.
2. Don’t overburden the team. Don’t make the estimate smaller than it really is likely to be and then push your team to follow it. The team will probably deliver the value that you need, but you might lose them to another company or project that doesn’t push them unrealistically and provides greater opportunity for a healthy work-life balance.
3. Consider risks. Some situations might occur that are out of your control. We should analyze such situations in advance and add additional time (or other resources) to accommodate.
4. Use experience from your previous projects. This can be really helpful and save lots of time. The same goes for past knowledge and skills.
5. Ask an expert. 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.