Testing Estimation

Application boundary considers users perspective. It indicates the margin between the software measured and the end user. It helps to identify what is available to the end user externally from the interface to interact with the internal of the system. This helps to identify the scope of the system.

Test Point Analysis is an approach for formulating all top-down methods. TPA is utilized for arriving at the estimated effort. TPA only covers the Black-box testing which is an estimate for the test activities. It can also be useful in the case where the test hour allowance has been predetermined. Risks can clearly be identified by comparing the objective TPA estimate with the help of the number of test hours that is predetermined.

Function points are measurement of a unit for software which resembles an hour measuring time. The functionality of the software is quantified by function points on the request provided by the customer primarily based on logical design. Function points measures software development and its maintenance consistently among all projects and enterprises.

Below are the steps in function points:

First Count ILF, EIF, EI, EQ, RET, DET, FTR and use the rating tables. After you have counted all the elements you will get the unadjusted function points.

Put rating values 0 to 5 to all 14 GSC. Adding total of all 14 GSC to come out with total VAF. Formula for VAF = 0.65 + (sum of all GSC factor/100).

Finally, make the calculation of adjusted function point. Formula: Total function point = VAF * Unadjusted function point.

Make estimation how many function points you will do per day. This is also called as "Performance factor".On basis of performance factor, you can calculate Man/Days.

Function points are a unit measure for software much like an hour is to measuring time, miles are to measuring distance or Celsius is to measuring temperature. Function Points are an ordinal measure much like other measures such as kilometers, Fahrenheit, hours, so on and so forth.

This approach computes the total function points (FP) value for the project, by totaling the number of external user inputs, inquiries, outputs, and master files, and then applying the following weights: inputs (4), outputs (5), inquiries (4), and master files (10). Each FP contributor can be adjusted within a range of +/-35% for a specific project complexity.

There are five methodologies most frequently used:

Top down according to budget

WBS (Work Breakdown Structure)

Guess and gut feeling

Early project data

TPA (Test Point Analysis)

TPA is a technique used to estimate test efforts for black box testing. Inputs for TPA are the counts derived from function points.

Below are the features of TPA:

Used to estimate only black box testing.

Require function points as inputs.

The dynamic elementary process moves data from an internal application boundary to an external application boundary or vice-versa. Example: Input data screen where a user inputs data into the application. Data moves from the input screen inside the application.

Static elementary process which maintains the data of the application either inside the application boundary or in the external application boundary. For example, in a customer maintenance screen maintaining customer data is a static elementary process.

The testing estimates derived from function points are actually the estimates for white box testing. So in the following figure the man days are actually the estimates for white box testing of the project. It does not take into account black box testing estimation.

An FTR is a file or data referenced by a transaction. An FTR should be an ILF or EIF. So count each ILF or EIF read during the process. If the EP is maintained as an ILF then count that as an FTR. So by default you will always have one FTR in any EP.

ILFs are logically related data from a user's point of view. They reside in the internal application boundary and are maintained through the elementary process of the application.ILFs can have a maintenance screen but not always.

EIFs reside in the external application boundary. EIFs are used only for reference purposes and are not maintained by internal applications. EIFs are maintained by external applications.

EIs are dynamic elementary processes in which data is received from the external application boundary. Example: User interaction screens, when data comes from the User Interface to the Internal Application.

EOs are dynamic elementary processes in which derived data crosses from the internal application boundary to the external application boundary.

An EQ is a dynamic elementary process in which result data is retrieved from one or more ILF or EIF. In this EP some input requests have to enter the application boundary. Output results exits the application boundary.

This section is the most important section. All the previously discussed sections relate only to applications. But there are other things also to be considered while making software, such as are you going to make it an N-Tier application, what's the performance level the user is expecting, etc. These other factors are called GSCs.