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 Requirement Specification/ Scope of work/Change request, Risk register template WBS, Quality Requirement, Field observation Estimate Estimation Sheet, Test Plan, Plan Estimated, Requirement Specification/ Scope of work, WBS, Quality Requirement, Software Package, Tasks Study requirement Output WBS and Estimation Sheet (4 columns) Estimation Sheet (updated) Test Plan Estimation 50 pages(A4) per day (Thai language)

Estimate the test effort

See Estimation Applied Defined in Test Plan

Prepare/Update test plan Follow the steps defined in test plan Make test cases Prepare test environment Run the test

Test Cases Test Environment Test Cases (Updated)

Page 5/8 Copyright 2008 by Cherapa Wannasuk

Input Defect report template

Test Plan, Defect Defect Summary report, Defect Summary report report Template, (4 columns are Modules, Quality, Work Package and Risk)

Tasks Report test results Follow up the fail test results Iteration, go back to step 1 for additional/change requirements Stop the test and report the final test result

Output Defect report Defect report (updated)

Estimation

1 day to collect day and 1 day to review

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 <= 5 6 -10 11 up 2 level 1.5 2 3 3-5 level 2 3 4 6 level up 3 4 5

Interface to others system and Quality required + 0.5 day to review completeness and correctness of identified interface and 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 Correctness Easy to use Maintainability Reliability Correctness Easy to use Maintainability Correctness Completeness Easy to use Traceability Reliability Correctness Easy to use Completeness Easy to use New Edit Remove Request Video New Edit Remove Reproduce Issue Rental (2) Late Rental (1) Promotion (1) Out of shelf (2) Input Quantity Compare Quantity Adjust Quantity Video Rental List Reserve List Fee List High Medium Low Low High Medium Low High High Medium High Medium Medium Medium High Low Low Low 1 1 1 1 1 1 1 1 2 2 1 1 1 1 1 2 2 2 15 15 3 5 10 10 3 5 5 3 3 3 3 3 5 10 10 5 Total 1.6 1.2 1.2 1.2 1.2 1.2 1.2 1.2 1.2 1.2 1.2

Video

Rental

Stock Count Report

1.2 1.2 1.2 17.2

Risk identify is coming from the risk calculation method.

Addition Estimated
These are the required tasks to complete the whole estimation procedure. 30% of the execution test effort 17.2 * 30% = 5.16 days Develop test cases 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. 5.16 days Develop test cases 17.2 + 1.37 = 18.57 days Test execution 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 100 100 100 100 100 Total 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