Time Estimation Technique & Tools that are Essential for your Software Testing

One of the key factors that determines the success of the software testing and development team is whether they are able to present the finished product in a timely manner. Timely project delivery is completely dependent on time estimation of the project. So time estimation is very important in software testing.

Having a clear time schedule and sticking with it is crucial to build a good reputation and keep clients happy.

That being said, it can be difficult to simply calculate the timeframe for a given testing project by simply eyeballing it.

Although an expert can come pretty close at judging the optimal time requirements of a project, I would like to use this article to go over five common time estimation techniques that every tester should be aware of.

#1 – Delphi Technique

Ah, Delphi. Who hasn’t heard about the famous oracle of Ancient Greece? Know thyself is a maxim that is equally valid for software testing as it is for life in general, though maybe I’d add: and thine software projects.

The Delphi technique consists of carrying out surveys from experts to obtain an average final estimation of the time-effort that a task is likely consume.

Each team member is assigned a task to be estimated and they collect information in multiple rounds. At the end of each round, the feedback obtained is analysed to reach a conclusion about how long the task is likely to take.

#2 – Functional Point Method

This technique is the polar opposite of the previous one, since in this case we analyse each task in terms of functional points, or, what the end-user will see on the screen.

In the functional point method, we assign each functional point a weighting that can range from simple (1) to medium (3) to complex (5). We then multiple the number of functional points in each category with the category weighting and add up the total.

The functional points total is then multiplied by the norm of 2 person-hours per functional point to arrive at the final time estimate for the whole project. Check out the example below.

#3 – Work Breakdown Structure

No need to look for therapy yet. Work breakdown in this case refers to what we’ve been doing all along: deconstructing the project into its elementary components.

Of course, you’ve heard the saying: don’t bite more than you can chew. Likewise, by breaking down the task into its detailed steps, team members can discover any functionalities, or even sub-functionalities, that they may have not considered in the original plan.

This exercise not only improves budgeting and helps create a tighter schedule around the project, but also fosters a sense of accountability and commitment among the team members, since each one shares the responsibility of completing a particular task.

#4 – Three-Point Estimation

The three-point estimation can be considered as a logical addition to the work breakdown structure technique.

After the project has been broken down into its component tasks, each task is given three types of time estimations (hence, three-point):

1. 1.     Optimistic estimate (A) — this is the time estimate from heaven, where everything goes swimmingly and all the required conditions are met.
2. 2.     Pessimistic estimate (B) — the time estimate from hell, a scenario where Murphy’s Law is proven beyond doubt.
3. 3.     Realistic estimate (R) — the most likely duration of the project under normal conditions.

To find the value for the time estimate (E) of the project, simply use the following formula:

E = (A + 4xR + B)/6

#5 – Planning Poker

Another application of the work breakdown structure, and infinitely more fun! We’ve already discussed in a previous post why planning poker works.

To estimate the time required for testing efforts on individual tasks, write down each task on a separate piece of paper, distribute to the team members and allow some time for a discussion to take place.

After the first round of discussion, each deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again.

This technique utilises the collective wisdom of the team to reach a fairly accurate estimation. We suggest using this free online tool if holding planning poker sessions in a single physical location is not possible.

4 Tips for better time estimation

In this article, I’ve gone over five common techniques that help you reach an accurate time estimate of the effort required to complete a testing task.

To conclude, I’d like to suggest four tips that I found useful in my own work to make even better time estimations for testing projects.

1.     Allow for buffer time: Cut yourself and your team some slack and add some extra time to account for any unforeseen circumstances. But don’t forget Parkinson’s Law: work expands to fill all time available, so make sure to (ab)use of buffer time only if necessary, otherwise stick to the original estimate.

2.     Take into account the bug cycle: The testing cycle is interlinked with the bug cycle, and any problems in stability of the software you’re working one may require additional time for developers to fix it, consequently extending the testing cycle as well.

3.     Time is money: Make sure to consider the availability of physical (and human) resources in your test estimation. Time availability alone isn’t enough, as lack of a particular resource can leave you waiting until it is available.

4.     Comparative testing: If you have worked on previous (or similar) versions of the current task, then you could base your estimates using data from the previous project.