There are two techniques for estimation covered by the ISTQB Foundation Syllabus.

1. One involves people with expertise on the tasks to be done and
2. Other involves consulting the people who will do the work .

The first one involves analyzing metrics from past projects and from industry data.

Let’s look at both of them one by one.

1. People with expertise on the tasks to be done:

In this process we ask the individual contributors and experts involves working with experienced staff members to develop a work-breakdown structure for the project. With that done, you work together to understand, for each task, the effort, duration, dependencies, and resource requirements. The idea is to draw on the collective wisdom of the team to create your test estimate.

Using a tool such as Microsoft Project or a whiteboard and sticky-notes, you and the team can then predict the testing end-date and major milestones. This technique is often called ‘bottom up’ estimation because you start at the lowest level of the hierarchical breakdown in the work-breakdown structure – the task – and let the duration, effort, dependencies and resources for each task add up across all the tasks.

Analyzing metrics can be as simple or sophisticated as you make it. The simplest approach is to ask, ‘How many testers do we typically have per developer on a project?’ Or another more reliable approach involves classifying the project in terms of size (small, medium or large) and complexity (simple, moderate or complex) and then observing on average how long projects of a particular size and complexity combination have taken in the past.

Sophisticated approaches involve building mathematical models in a spreadsheet that look at historical or industry averages for certain key parameters – number of tests run by tester per day, number of defects found by tester per day, etc. – and then plugging in those parameters to predict duration and effort for key tasks or activities on your project.

The tester-to-developer ratio is an example of a top-down estimation technique, in that the entire estimate is derived at the project level, while the parametric technique is bottom-up, at least when it is used to estimate individual tasks or activities.

We prefer to start by drawing on the team’s wisdom to create the work breakdown structure and a detailed bottom-up estimate. We then apply models and rules of thumb to check and adjust the estimate bottom-up and top-down using past history. This approach tends to create an estimate that is both more accurate and more defensible than either technique by itself.

2. Consulting the people who will do the work:

Even the best estimate must be negotiated with management. Negotiating sessions exhibit amazing variety, depending on the people involved. However, there are some classic negotiating positions. It’s not unusual for the test leader or manager to try to sell the management team on the value added by the testing or to alert management to the potential problems that would result from not testing enough.

It’s not unusual for management to look for smart ways to accelerate the schedule or to press for equivalent coverage in less time or with fewer resources. In between these positions, you and your colleagues can reach compromise, if the parties are willing.

Our experience has been that successful negotiations about estimates are those where the focus is less on winning and losing and more about figuring out how best to balance competing pressures in the realms of quality, schedule, budget and features.

Other popular articles:

• What is test estimation? Related Factors, Estimation Techniques
• What is Planning Poker? Effort estimation in Agile methodology
• Estimating what testing will involve and what it will cost?
• What is Whole-Team Approach in Agile methodology?
• What are the factors affecting test effort in software testing?