teSting eStimation 167
with the formula so that you only have to put the quantity in the appropriate
section and you get the final value.
Table 24 EQ rating table
EQ Rating Table
Data Elements
FTR 1 to 5 6 to 19 Greater than 19
Less than 2 3 3 4
2 or 3 3 4 6
Greater than 2 4 6 6
Table 25 ILF rating table
ILF Rating Table
Data Elements
RET 1 to 19 20 to 50 51 or more
1 RET 7 7 10
2 to 5 7 10 15
Greater than 6 10 15 15
EIF Rating Table
RET 1 to 19 20 to 50 51 or more
1 RET 5 5 7
2 to 5 5 7 10
Greater than 6 7 10 10
Steps used to Count Function Points
This section will discuss the practical way of counting FPs to end up with the
number of men/days on a project.
1. Count the ILF, EIF, EI, EQ, RET, DET, FTR (this is basically all sections
discussed above): This whole FP count will be called the “unadjusted
function point.”
168 Software teSting interview QueStionS
2. Then put rating values 0 to 5 for all 14 GSCs. Add the total of all 14 GSCs
to set the total VAF. The formula for VAF
5 0.65 1 (sum of all GSC
factors/100).
3. Finally, make the calculation of adjusted function points. Formula: Total
function point
5 VAF * unadjusted function point.
4. Make an estimation of how many function points you will cover per day.
This is also called the “performance factor.”
5. On the basis of the performance factor, you can calculate men/days.
Let’s try to implement these details in a sample customer project.
Sample Customer Project
We will be evaluating the customer GUI, so we will assume what the customer
GUI is all about.
The following is the scope of the customer screen:
The customer screen will be as shown here.
After inputting the customer code and customer name, they
will be verified with a credit card check.
n
n
Figure157 Custom screen
teSting eStimation 169
The credit card check is an external system.
Every customer can have multiple addresses.
The customer will have add and update functionality.
There is one ILF in the customer screen:
The customer ILF.
There is one EIF in the form.
Credit card system.
The following are the ILF counting rules:
ILF are logically related data from the user’s point of view.
Customers and customer addresses belong logically to the
customer category.
ILF reside in the internal application boundary and are
maintained through the elementary process of the application.
Customer resides inside the application boundary as we have
full access over it.
The following table gives the appropriate ILFs:
n
n
n
n
n
n
n
n
ILF Customer
Description Number of DETs Number of RETs
There are total 9 DETs, all 9 1
add and update buttons,
even the credit check button,
the address list box, check box
active, all text boxes. There is
only one RET, the customer
addresses.
So according to the ILF
Total function 7
ranking table
Table 26 ILF for the customer
170 Software teSting interview QueStionS
EI Credit Card Information
Number of DETs Number of RETs
Description
The credit card information referenced
is an EIF. Note this file is only referenced
for the credit card check. 1 1
There’s only one textbox credit card
number and hence one DET is put
in the side column. And RET is 0.
Looking at the rating table the
total FP is 5.
So according to the above ranking table Total function
5
Table 27 EI for the customer
EIF lies outside the application boundary.
The following EIF rules were defined in the previous sections:
It is a dynamic elementary process in which data is received
from the external application boundary. Customer details are
received from the external boundary, that is, the customer
input screen.
EI may maintain the ILF of the application, but it’s not a
compulsory rule. In this sample project the customer ILF is
maintained. So there are two EI: one for add and one from
update.
While counting EI I have seen many people multiply it by 3.That means
we are going to do all CRUD functionality (ADD, UPDATE, and DELETE).
Here the customer screen has add and update. We can say that 2
* 6; that 5
12 FP for this EI customer. But later when someone refers to your FP sheet
he will be completely lost.
n
n
teSting eStimation 171
EI Update Customer
Description Number of DET Number of RET
There are 9 total DETs, all add and update
uttons, even the credit check button, the
address list box, check box active, all text
boxes.There are 3 FTRs, one is the
address, the second is the credit card
information, and the third is the
customer itself. 9 3
So according to the above ranking table Total function
6
Table 29 EI for the update customer
The following are rules to recognize EO:
Data should cross application boundaries and should involve
complex logic.
Credit card check processes can be complex as credit card API complexity is
still not known. Credit card information crosses from the credit card system
to the customer system.
n
EI Add Customer Number of DETs Number of FTRs
Description
There are total 9 DETs, all add and
update buttons, even the credit check
button, the address list box, check
box active, all text boxes.
There are 3 FTRs, one is the address
and the second is the credit card
information, and the third is the
customer itself. 9 3
So according to the above ranking table Total function
6
Table 28 EI for the add customer
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.