Test Effort Estimation Model

                                                                                                                                     -Jagadees Byreddy

1          Introduction

Effective software project estimation is one of the most challenging and important activities in software project management. Proper project planning and control is not possible without a sound and reliable estimate. Under-estimating a testing project leads to under-staffing it (resulting in staff burnout), under-scoping the quality assurance effort (running the risk of low quality deliverables), and setting too short a schedule (resulting in loss of credibility as deadlines are missed).

Today’s e-business applications impose new challenges for software testing. Some of the commonly known challenges are complex application scenarios, extensive third party integration, crunched testing life cycles and increased security concerns. These factors inherently make testing of e-business application far more complex and critical than conventional software testing.

Traditionally, estimation of efforts for testing has been more of a ballpark percentage of the rest of the development life cycle phases. This approach to estimation is more prone to errors and carries a bigger risk of delaying the launch deadlines.

Test Effort Estimation Model is an approach for doing an accurate estimation of functional testing projects. This approach emphasizes on key testing factors that determine the complexity of the entire testing cycle and gives us a way of translating test creation efforts to test execution efforts, which is very useful for regression testing estimation. In other words the Test Effort Estimation Model is a way of representing the efforts involved in testing projects.

2          Test Effort Estimation Methodology

Given below is an overview of different phases involved in Test Effort Estimation Model for manual test execution. Each phase is explained in detail in subsequent sections.

2.1        Identify Test Procedures

Test Effort Estimation model starts with identification of all the high-level test procedures based on the application requirements. These procedures when put together would form the whole application under test (AUT). Lets take an example to see what we mean here by procedures. Consider www.yahoo.com is the AUT. Some of the modules for this AUT would be Community, Searching, Shopping, Business etc

The next step would be to list all the procedures that each module has.  In our previous example, consider Community as our module which would have procedures like Mail, Chat, Clubs etc.

2.2        Identify Test Cases in a Test Procedure

Next we would identify all Test Cases corresponding to each individual procedure. If Mail service is our feature than its corresponding Test Cases would be Composing, Replying, Move etc.

Here’s an outline of our previous example.

MODULE	PROCEDURE	TEST CASES
Community	Chat	Compose a new mail
Search	Mail	Reply to a  mail
Shopping	Clubs	Move to a folder

2.3        Classify Test Cases as Simple/Average/ Complex

Classify the identified test cases as being Simple, Average or Complex. The standard weights range from 0 to 3.

1-3 ----> Simple

4-7 ----> Average

>8 ----> Complex

Complexity Type	Complexity of Test Case	Interface with other Test case	Number of Verification Points	Baseline Test Data
Simple	< 2 transactions	0	>2	Not Required
Average	3-6 transactions	<3	3-8	Required
Complex	>8 transactions	>3	>8	Required

2.4        Identify factor and complexity weight for Test Creation parameters

In this stage, the factors that will affect the Test Creation/execution are identified. Typical factors which might be considered are listed below:

1.       Domain Complexity

2.       Integration with other Hardware devices such as Hand-held devices, Scanners, Printers

3.       Multi-lingual Support

4.       Configuration Management

5.       Preparation of Test Bed

6.       Stable Requirements

7.       Operating System Combinations

8.       Browser Combinations

The ‘Factor Weight’ is the importance of the factor to the application.

The ‘Complexity Weight’ is a measure of the factor’s impact on testing

For eg., for an insurance project, the factor weight for ‘domain complexity’ can be 2 but the complexity factor can be high, say 4 or 5, as the domain knowledge is critical for testing the application.

2.5        Calculate Adjustment factors for Test case generation and test execution

Give Adjustment Factors for the test case classifications.

Out of the factors identified in Section 4.4, identify which factors will affect Test Case generation and which will affect Test Case Execution. Include them in the appropriate sections in the spreadsheet.

The Adjustment factor for Test Case generation and Test Execution are calculated.

2.6        Calculate Person Hours for Test Case generation and Test Case execution

Based on the AUT, calculate the person hours required in generating the test cases.

For eg., a person might require an average of 0.3 person hours for a test case point (A Test Case Point is a test case + some adjustment factor).

Calculate the person hours required for executing each test case under the simple, average or complex classification. This should be calculated based on the number of iterations estimated for a test case.

For eg., a ‘simple’ test case might require 0.3 person hours (~20 mins) for being executed for 2 iterations, an ‘average’ test case might require 1 person hour for 2 iterations and a ‘complex’ test case might require 2 person hours for 2 iterations (depending on the application).

3          Effort Calculation

The effort is calculated in terms of Person Hours and Person Days based on the values specified in the spreadsheet.