Methodology of Test Effort Estimation

est Estimation in Software Testing industry is similar to time management that we do in our day to day lives. In order to understand what test effort estimation is, let us understand the term estimation first.

Estimation is the intelligent anticipation of the amount of work that must be done and the resources (human, financial resources, equipment resources and time resources) needed to perform the work at a future date, in a defined environment, using specific methods.

Most of you who have never done Test estimation before must have actually done it though you haven't realized it.

Let's consider an example for this. You want to attend your office at 9:00. So you estimate the time it would take you to reach office say, 45 minutes. And you take 15 minutes for your morning walk, 30 minutes to get ready & 20 minutes for breakfast. So to reach office on time you would need to wake up no later than 7:10AM.

Now let us understand test effort estimation.

Test estimation is the process of estimating the testing cost, testing effort, testing size & schedule of testing for a particular project on software testing under a specific environment, with the help of specified methods, testing tools & test techniques.

Software Testing estimation is important as it is directly linked with the project cost & deadline. Estimation is based on:

# Documents/Knowledge available: Requirement Specification Document, Domain Knowledge, Tool Understanding

# Assumptions: Requirement Doc is complete, builds will be stable etc.

# Calculated Risks: Manpower cost, lack of system understanding, backup resources available or not etc.

# Past Experience: Past experience or historical data

There are different standard & non-standard methods of doing test estimation. Many Managers/Leads are not comfortable in doing estimation as it is a time consuming activity. So they follow a non-standard way of estimation based on their past experience. But, if they are asked to work on some new technology/domain then it is difficult for them to do test estimation.

Methods of software test estimation:

1) Function Point Analysis / Test Point Analysis:
FPA is an ISO recognized method. Measure the functional size of an information system / application. Size reflects the amount of functionality from the functional or user, point of view. Independent of the technology used to implement the system and is totally dependent on the SRS (Specification Requirement Document)

Formula to calculate FP:

FP = UFP * VAF

Where UFP – Sum of complexities of basic functions - Internal logical files (known as ILF), External interface files (known as EIF), External inputs (known as EI), External outputs (known as EO), External enquiries (known as EQ)

VAF – Value adjustment factor.

Number of the test cases = FP *1.2 (Caper Jones formula)

Test effort = Number of the test cases * (%age of development effort/100)

Drawback: Detailed SRS is required.

2) Work Breakdown Structure (WBS):
Break down each testing task (map the task with each deliverable as per requirement document) into the smallest chunk or sub-tasks. Now do the estimation for each sub task.

3) Point Estimation Technique:
It resembles with WBS estimation method, break down every testing task into sub task & then do following three estimations on each entity:

# Best Case/ Positive scenarios: Where everything goes right, P

# Worst Case/Negative scenarios: Where everything goes wrong, N

# Average Case/Exceptional scenarios: Where few things go right & few deviates from the actual plan, A

Test Effort Estimate = P + 4*N + A/6

4) Delphi Method:
It is similar to WBS estimation method; here task & sub-tasks are allocated to the team members or some experts. Then team members/experts give the estimate that how much time they will take to complete each task. And finally their estimates are consolidated to reach the final estimate for each task.

5) Use Case Points:
Use case is a document, which describes the behavior and interaction of the system as the reaction to a specific query or action of an actor. Here actor means either an end-user or the stakeholder. An interaction is initiated by the primary actor with some specific objectives in mind. The system then provides response by safeguarding the interests of all concerned actors. According to the requests made & various conditions surrounding those requests, system behavior/ flow can be opened up. Test cases are based on the Use Cases.

Conclusion: Estimation is not a close-ended document, but a live document. You should keep your estimation document updated as and when you sense a change from actual happening in field. It should be reviewed continuously during course.