The Most Popular Software Testing Estimation Techniques
We all know that software testing is a fundamental process without which it is impossible to develop a high-quality software. But not all of us understand that there are particular parameters which should be set up before the testing process begins. Why is it so important?
Imagine a client, who came to the software company to talk about details of the project. We guarantee that he will be interested in two questions only: how long will all (testing) process take and how much will it cost. Obviously, to answer these questions developers need to estimate certain parameters, namely "Price", "Time", "Resources" and "Human Skills".
Let us clearly define what does each parameter mean for the testing management team.
Cost (Overal project budget). It means how much money is needed to finish the project.
Time. Every project has its own deadline. Therefore, the management team needs to initially calculate how long will it take to perform each part of the project. Remember, time is one of the most important resources developers have.
Resources. Here we assess what resources do we have and what resources do we need to fully complete the project.
Human Skills. It means how experienced your team is to meet the challenge. This parameter directly affects the time needed to complete the project. For that reason evaluation and optimization of the human-skills parameter is a priority in the software testing estimation process.
Of course, if we are dealing with the small project, all of these variables are considerably simplified. But what if we have got a big project, which has a tight deadline. Therefore, it is important to make evaluations of testing efforts in advance.
So how can we evaluate or even predict these parameters? In fact, everything is not as hard as it sounds. By following an unsophisticated strategy we can estimate testing efforts properly. Usage of the certain estimation techniques in software testing helps to simplify all the estimation process.
For the evaluation of the whole process, testing managers use following testing estimation techniques:
Work Breakdown Structure (WBS) Technique;
Three Point Estimation Method;
Functional Point Method (FPM).
These are the most effective methods for software testing, implementation of which exclude quite a number of errors during the test process.
Work Breakdown Structure
This is a really powerful method if we are talking about qa estimation techniques. The essence of this method is that we divide a common task into subtasks (or sub-modules). These subtasks, in turn, are divided into smaller components. And so on. Until we get as detailed structure as it is possible.
For example, if we’re talking about a test plan establishing, sub-modules are:
Test scripts creation;
Test cases creation.
If we're talking about errors report, the sub-modules are:
Errors report creation;
Reporting the errors.
All other stages of the testing process can be divided into sub-components the same way.
The advantage of this method is that the team tests project step by step. In addition to it, each team member receives a specific task related to a specific sub-module. This helps to avoid such situations, when nobody knows what to do or when everybody does all at once – you will agree that this isn’t the best option.
In the case of WBS technique, each member assumes the responsibility and realizes what results should be given to the team in a certain interval of time.
To sum up, the WBS helps to clearly plan the testing process and, as a consequence, to plan a budget that will be given for the implementation of each sub-module.
Three Point Estimation
The essence of this method is very similar to the WBS technique: here we just break each item into sub-items and evaluate them separately. According to this method, the estimation process is based on knowledge/data/experience that team got from the past projects. What does that mean? In three point estimation method we evaluate each sample according to one criterion (or possible scenario):
A - Optimistic case. This is the realization of the best scenario possible. During the testing process, everything worked the way it has to be. No problems have arisen at any stage.
M - Most likely case. This version means that team had some difficulties, during the testing process, but still the task was fully implemented in time.
B - The Worst case. This value assumes the worst scenario case when all the testing process went wrong.
So how to do software testing estimation using this method?
Let's say your test team has received a draft. If draft implementation took:
100 person hours. This is a good indicator (or Optimistic case). In other words, you have a talented team that can cope with the tasks in the shortest time possible.
150 person hours. Most likely case. Your team needed more time to complete the task. Yet you met deadlines and you have got all the resources needed to finish a draft.
200 person hours. B - case. Your team does not cope with the task. Deadlines shifts and your team need more resources to complete the project.
Of course, these data are approximate Here, it’s just important to understand what will be the best scenario for your team, and what - the worst one.
Using Three point estimation method one can calculate how much efforts it will take to complete the project. This can be calculated with the help of the formula:
E = (a + 4m + b) / 6;
Where a = 100; m = 150 and b = 200;
E - is the average time needed to complete a task.
So, what do we have:
E = (100 + 600 + 200) / 6;
E = 150 person hours.
In order to make our estimations more accurate, we need to calculate the limits (Standart Deviation), in which E may change. SD value can be calculated as:
SD = (b-a) / 6;
SD = (200-100) / 6;
SD = 16.7
The final estimation template can be represented as follows:
To perform the task team needs 150 + - 16.7 person hours.
Functional Point Method
As with the WBS method, here we break the project into smaller modules and depending on how complex each module is, assign a specific functional point (FP) to it. The more complicated unit is, the higher rate (FP) it gets. According to this technique, the whole project is broken down into 3 groups: complex (5 functional points), medium (3) and simple (1) group. Each group can have several stages of one project at the same time.
So, the parameters we need can be calculated by the formula:
Total Effort = Total FP * Estimate Defined per FP;
Total Effort can be considered as time, size or cost of a project.
Let’s look at a simple example. We have divided all project into several modules. Now we have 2 complex modules, (each of which has the FP equals 5) 10 medium, and 5 simple modules. According to this Total FP will be equal to:
Total FP = 2 * 5 + 10 * 3 + 5 * 1 = 45;
Estimate defined per FP is a given value which test managers put into calculations with respect to time, cost or size (5 hours / points, 10 $ / points, etc). This value usually bases on the team experience. Let's consider this parameter equals to 5 hours/points.
Total Effort = 45 * 5 = 225 person hours.
This means that in order to perform a specific project, we need 225 person hours.
Note that programming language, team skills does not matter for a given estimation method. This technique is based on documents such as the SR, for example.
To Sum Everything Up
So here we are. These are all points we wanted to cover about the most popular software testing estimation techniques.
Of course, these methods are not perfectly accurate. Do not forget to take into account a possible errors and calculation missings for the test case estimation techniques. For a more accurate calculation of all efforts try to take into account additional parameters, such as an extra buffer time. In fact, no one can say exactly how long it will take to complete the test task. Even the most experienced team may be confused with unforeseen difficulties while completing the tasks.
Be sure to consider the experience of past projects. This can significantly help to correctly predict all the options you want. Just keep in mind that calculations, it is just a calculations. If things don’t go according to a plan it’s better to stop and recalculate them. It’s much better than doing the next step with a hope that it will be fixed later.
Only responsible and sensible decisions, That's what we need.
In fact, this is the principle, we are guided by in our team. 15+ years on the software market have given our company a wealth of experience not only in development but also in testing processes. Experience + agile approach of a skilled team is a perfect formula for a high-quality product. For more detailed information about our cases or peer reviews on the questions you are interested in, please contact us: firstname.lastname@example.org.