Estimation procedure applied to Functional

Requirements
(WBS approach)
By Ms.Cherapa Wannasuk
Position: Senior Consultant
Gosoft (Thailand) Co.,Ltd.
E-mail: cherapa@yahoo.com, cherapa@gosoft.co.th
Tel: + 662-677-9471
Mobile: +6689-140-8022

Abstract
There are a lot of estimation theories such as COCOMO II, Function Points, and etc.
They are not defined for testing. When we are requested to make estimation for testing
we have to do a lot of things. It is not easy to do it. I studied PMBOK 3rd and found the
great input to my estimation procedure. I start by Scope Management, Work break down
structure. I review quality required in Project Planning and then I continue to do Risk
Management, Risk identification, Quantitative and Qualitative risk analysis. The result is
incredible. I get the good estimated data. It is the first estimated that I have to revise it
when I get more requirements in detail. I hope this study will show you some idea to
make your own estimate.

Page 1/8
Copyright 2008 by Cherapa Wannasuk
Contents
Abstract ............................................................................................................................... 1
Introduction......................................................................................................................... 3
Work Breakdown Structure ................................................................................................ 4
Estimation Applied ............................................................................................................. 6
Addition Estimated ......................................................................................................... 7
Drive to make and execute Test Cases ............................................................................... 8
Summary............................................................................................................................. 8

Page 2/8
Copyright 2008 by Cherapa Wannasuk
Introduction
In the pass, I always followed the estimated data from Project Manager. I don’t know
where is the data come from. Normally I had to plan the test based on the effort that I got.

The testing job is started from requirement studying, preparing the test plan, making the
test cases, executing the test cases, making the results report and following up the fail
results. I have to make sure that it is fixed. Every step is time consuming. Finally, I found
that the effort that I have got from Project Manager is under estimated.

These are the testing procedure.

1. Study requirement
2. Estimate the test effort
3. Prepare/Update test plan
a. Follow the steps defined in test plan
i. Develop test cases
ii. Prepare test environment
iii. Run the test
iv. Report test results
v. Follow up the fail test results
vi. Iteration, go back to step 1 for additional/change requirements
4. Stop the test and report the final test result

The information shown in this article is one of the affective ways to show the project
manager about my estimation.

These are the estimation procedure steps.

1. The procedure started from study the work break down structure, if available. You
need to do it by yourself in case you don’t have.
2. Note the quality assigned in each deliverables
3. Look at each work package, and follow these steps;
a. Put the required quality in each individual one
b. Find the way to prove it works as defined in functional requirement
c. List the tasks that help you check the quality required
d. Give the estimated time to run the test
4. Perform risk identification by looking at each individual work package and assign
qualitative and quantitative data.
a. Give the % increase or % decrease to each risk identify in each work
package
5. Calculate time required to perform test process

The next following topics are dealing with detail in each individual step.

Page 3/8
Copyright 2008 by Cherapa Wannasuk
Work Breakdown Structure
In PM 3rd, the Create WBS is subdividing the major project deliverables and project work
into smaller, more manageable components. I mean the product
components. It is shown you these.
√ Is based on scope statement
√ Provides means for defining total scope of work
√ Depicts hierarchical listing of deliverables and activities
√ Includes project management as well as product deliverables
√ Describes industry “standard” product lifecycles

These are objectives of WBS.

√ Ensures all work needed is included
√ Ensures unnecessary work is excluded
√ Serves as an efficient tool to build consensus
√ Identifies deliverables and activities
√ Understand amount of resources needed, from a roles
perspective
√ Understand relationship dependencies within the WBS only
√ Foundation for estimate
√ Becomes input to:
o Activity definition
o Resource planning
o Cost estimating
o Risk Management planning

Page 4/8
Copyright 2008 by Cherapa Wannasuk
This is the simple WBS that I will use through out my article. The customer requested
our company to develop the customer video rental system. The first time the scope is
summarized. There are five function required to complete in this software product.
Reliability is required to ensure that all information are properly recorded at the right
time and correct.

There are 3 levels in the WBS. Before I continue to the next topic I will show you the
first estimation for my work. I create the table that I used it for the fundamental of all
testing estimation routine. I set 1 day equal to 8 hours.

Input Tasks Output Estimation

Requirement Study requirement WBS and 50 pages(A4)
Specification/ Scope Estimation per day (Thai
of work/Change Sheet (4 language)
request, Risk register columns)
template
WBS, Quality Estimate the test effort Estimation See
Requirement, Field Sheet Estimation
observation Estimate (updated) Applied
Estimation Sheet, Prepare/Update test plan Test Plan
Test Plan, Plan Follow the steps defined in Defined in
Estimated, test plan Test Plan
Requirement Make test cases Test Cases
Specification/ Scope Prepare test Test
of work, WBS, environment Environment
Quality Requirement, Run the test Test Cases
Software Package, (Updated)

Page 5/8
Copyright 2008 by Cherapa Wannasuk
 Input Tasks Output Estimation
Defect report template Report test results Defect report
Follow up the fail Defect report
test results (updated)
Iteration, go back to
step 1 for
additional/change
requirements
Test Plan, Defect Stop the test and report the
Defect 1 day to
report, Defect final test result Summary collect day
Summary report report and 1 day to
Template, review
(4 columns are Modules, Quality, Work Package and Risk)

Estimation Applied
One of the inputs that I used for my estimation is the Field observation Estimate and Plan
Estimated. I use my experience to make this table.

Test Plan Estimate

WBS Level Number of first level package Interface to others system and Quality
<= 5 6 -10 11 up required
2 level 1.5 2 3 + 0.5 day to review completeness and
3-5 level 2 3 4 correctness of identified interface and
6 level up 3 4 5 quality required

Field observation Estimate

Number of field Data Source/Condition
<=3 4-7 8-10 11 up
1-10 (18) 1.2 (96) 6.4 (178) 11.8 (~350 Up) 23
11-20 (24) 1.6 (118) 7.8 (230) 15.3 (~500 Up) 33
21-30 (27) 1.8 (132) 8.8 (262) 17.4 (~650 Up) 43
Reference: ALLPAIRS by James Bach, james@satisfice.com, www.satisfice.com
Number in the blanket is calculated from ALLPAIRS. I used the maximum number
of field and Data Source/Condition as the input.

Normal estimated: 15 cases per day, 1 day = 8 hours.

Data Source = List of the source that is used to be input.

For example;
√ Put 2 if the data is came from 2 documents.
√ Put 3 if the data is used by 3 departments
√ Put 4 if the data is entered by 4 different departments.
Condition = List of the condition required to operate these fields.
For example;
√ Put 2 if the data will be shown by two different conditions.

Page 6/8
Copyright 2008 by Cherapa Wannasuk
 √ Put 3 if the data will be captured via validation of 3 cases.

The estimation is going to be defined in the table below.

Modules Module Work Package Risk Data Data Fields Effort
Quality Source (Observation) (day)
Customer Reliability New High 1 15 1.6
Correctness Edit Medium 1 15
Easy to use Remove Low 1 3 1.2
Maintainability Request Video Low 1 5 1.2
Video Reliability New High 1 10 1.2
Correctness Edit Medium 1 10
Easy to use Remove Low 1 3 1.2
Maintainability Reproduce High 1 5 1.2
Rental Correctness Issue Rental (2) High 2 5 1.2
Completeness Late Rental (1) Medium 2 3 1.2
Easy to use Promotion (1) High 1 3 1.2
Traceability Out of shelf (2) Medium 1 3 1.2
Stock Reliability Input Quantity Medium 1 3 1.2
Count Correctness Compare Quantity Medium 1 3
Easy to use Adjust Quantity High 1 5
Report Completeness Video Rental List Low 2 10 1.2
Easy to use Reserve List Low 2 10 1.2
Fee List Low 2 5 1.2
Total 17.2
Risk identify is coming from the risk calculation method.

Addition Estimated
These are the required tasks to complete the whole estimation procedure.
Develop test cases 30% of the execution test effort 17.2 * 30% = 5.16 days

There are project risks that will be affected the estimation effort directly.
Project Risks Range % effected Add to estimate
Unclear scope 1-10% 5% 17.2 * 5% = 0.86 day
New technology 1-10% 1% 17.2 * 1% = 0.17 day
Inexperience staffs 1-10% 2% 17.2 * 2% = 0.34 day
Total 1.37 days
The estimation topics will be depending on project risk. I will go back to update this
estimate when change is occurred.

It the test plan these two tasks will be completed.

Develop test cases 5.16 days
Test execution 17.2 + 1.37 = 18.57 days

I noted quality and risk in the table above. I can identify the quality deep down to each
individual work package.

Page 7/8
Copyright 2008 by Cherapa Wannasuk
Drive to make and execute Test Cases
This is the table that will be used to adjust the estimation based on the quality required. I
have to identify the importance of each quality. Please remember we can not get all
quality in equal so we have to arrange them with number. You can put more quality
characteristic in this table base on your application requirements.
Quality Relative importance
characteristic Customer Video Rental Stock Report
Reliability 30 30 50
Correctness 30 30 30 30
Completeness 30 50
Manageability
Security
Usability
Connectivity
Continuity
Traceability 20
Flexibility
Functionality
Easy to use 20 20 20 20 50
Reusability
Infrastructure
Suitability
Maintainability 20 20
Performance
Portability
Testability
Efficiency
Total 100 100 100 100 100

I use this value to drive test cases and test scripts. For module customer, the test cases
must have 30% related to reliability, 30% related to correctness, 20% related to easy to
use and 20% related to maintainability.

The risk identification will help me to decide which work package I have to test first. In
case the time is limited I can discuss with the project manager to skip the low risk work
package and perform high risk testing first.

Summary
Estimation is not easy but it is not difficult till you can not do it. The first estimation will
not be good as we thought. It will get better and better until it is very close to the actual
work we perform. This article is the guideline how I perform estimate. WBS and WBS
dictionary is very helpful if it is already defined. If it is not I can get it from the scope of
work or requirement specification. I can say that it is the fundamental input to the test
estimation procedure.

Page 8/8
Copyright 2008 by Cherapa Wannasuk