Académique Documents
Professionnel Documents
Culture Documents
Software Testing
In order to be a successful in estimating, the software test project and proper execution are significant as the
software development life cycle. Software testing estimation techniques play a very important role in making the
good reputation with the client while bidding the project for testing.
One of the most important factors while estimating testing efforts is the experience on varied projects for the
software test life cycle. Apparently one cannot just put some number of days for any task or taking the old time
formula of one third of the development effort. This is one of the most widely used estimation technique by the
companies offering software testing services. It is merely due to the fact that this method is not based on any
For any software testing estimation technique, it is highly recommended that following factors should be taken
into account:
Historical data for the previous estimation for improvement and accuracy
Resources availability (Like vacations, holidays, and sick days can have a great impact on your estimates)
In the recent years there were many techniques that have been developed for estimating the software testing.
These techniques are:
Percentage distribution
Best Guess
Ad-hoc method
Experience Based
3-Point Software Testing Estimation Technique is based on statistical methods in which each testing task is broken
down into sub tasks and then three types on estimation are done on each tasks.
Whereas P = Positive Scenarios or Optimistic Estimate (Best case scenario in which nothing goes wrong and all
E = Exceptional Scenarios or Pessimistic Estimate (worst case scenario which everything goes wrong.)
Use-Case Point Method is based on the use cases where we calculate the un-adjusted actor weights and un-
Use case is a document which well specifies different users, systems or other stakeholders interacting with the
concerned application. They are named as ‘Actors’. The interactions accomplish some defined goals protecting the
Un adjusted actor weights = total no. of actors (positive, negative and exceptional)
Un adjusted use case point = Un adjusted actor weights + Un adjusted use case weight
Adjusted use case point = Unadjusted use case point * [0.65+ (0.01 * TEF]
It is created by breaking down the test project into small pieces. Modules are divided into sub-modules. Sub
modules are further divided into functionalities and functionalities are divided in sub-functionalities.
Review all the requirements from Requirement Document to make sure they are added in WBS. Now you figure
out the number of tasks your team needs to complete. Estimate the duration of each task.
Same as above WBS, In Wideband Delphi Method, work breakdown structure is decomposed for each task and is
distributed to a team comprising of 3-7 members for re-estimating the task. The final estimate is the result of the
summarized estimates based on the team consensus. This method speaks more on experience rather than any
statistical formula. This method was popularized by Barry Boehm to emphasize on the group iteration to reach to a
consensus where the team visualized on the different aspects of the problems while estimating the test effort.
The FP technique is a direct indicator of the functionality of software application from the user's perspective. This
is the most accepted technique used to estimate the size of a software project.
This technique is a part of TMap. Base of this technique is function point technique. Here we convert function
points into test points. In Test Point analysis, we usually carry out the following:
Environmental Factor
Productivity Factor
Control Factor
In Testing, This estimation is based on requirement specification document, or a previously created prototype of
the application. To calculate FP for a project, some major components are required.
The major components are:
1. Internal Files
2. External Interfaces
1. User Inputs
User Inquiries
Total Actual Effort, TAE = (Number of Test cases) * (Percentage of development effort /100)
This method is done in a case when a detailed low level design document or requirement document is available (i.e
measure of function point is available) & Previous data for development and testing is available.
ESTIMATION RULES
All estimation should be based on what would be tested, i.e., the software requirements. Normally, the software
requirements were only established by the development team without any or just a little participation from the
testing team. After the specification have been established and the project costs and duration have been
estimated, the development team asks how long would take for testing the solution. The answer should be said
Then, the software requirements shall be read and understood by the testing team, too. Without the testing
Before estimating, the testing team classifies the requirements in the following categories
Critical: The development team has little knowledge in how to implement it;
High: The development team has good knowledge in how to implement it but it is not an easy task;
The experts in each requirement should say how long it would take for testing them. The categories would help
All estimation should be based on previous projects experience/ knowledge. If a new project has similar
Organization should create an OPD, Organization Process Database, where the project metrics are recorded.
The testing team continues using the old process and the spreadsheet. After the estimation is done following the
new rules, the testing team estimates again using the old process in order to compare both results.
Normally, the results from the new estimate process are cheaper and faster than the old one in about 20 to 25%. If
the testing team gets a different percentage, the testing team returns to the process in order to understand if
All decisions should be recorded. It is very important because if requirements change for any reason, the records
would help the testing team to estimate again. The testing team would not need to return for all steps and take
the same decisions again. Sometimes, it is an opportunity to adjust the estimation made earlier.
A spreadsheet containing metrics should be created that help to reach the estimation quickly. The spreadsheet
calculates automatically the costs and duration for each testing phase.
The template could contain some sections such as: cost table, risks, and free notes to be filled out. This tool could
show the different options for testing that can help the customer decides which kind of test he needs.
All estimation should be verified. Another spreadsheet for recording the estimations should be created. The
estimation is compared to the previous ones recorded in a spreadsheet to see if they have similar trend. If the
estimation has any deviation from the recorded ones, then a re-estimation should be made.
Estimation should cover all kind of risk like resource availability, product down time, skill improvements, learning
capability etc.
Scenario:
Suppose you have a project that you estimate will take a 10 person team 300 days to complete. (3000 workdays -
Knowing that there are 365 working days in a year (52 weeks x 5 days), without holidays, means that the project,
Suppose the average year includes 12 days company holidays (total impact = 12x10 people = 120 daysx1.13years =
136 days)
Suppose also that the average employee takes 4 sick days and 3 comp days off a year (total impact = 7 x 10 people
= 70 x 1.13 = 79)
Suppose also that the average employee takes 7 work days of vacation a year (total impact = 7 x 10 people = 70 x
1.13 = 79)
Suppose also that each employee loses 3 days out of each year for training (30 days)
Total duration change due to employee holidays, sick time, vacation and training = 136+79+79+30=324
Total workdays for the project is now 3000+324 = 3324 or a 10.8% increase in duration (300 day schedule is now