1

Aligning Function Point Counting and Test

PlanningChris Francis, CSTE

Senior Consultant

Nestlé Purina Petcare CompanyCheckerboard SquareSt. Louis, MO 63164

2

ContentBrief Background on TestingSimilarities Between Counting and TestingExample

3

What is Testing?Operating a system or application under controlled conditions and evaluating the results

Includes both normal and abnormal operating conditionsOriented toward detection

A process to measure software qualityAn input to the judgment of risk

4

Why Test?

Reduction of problems occurring in production systemsReduction of software support costsIncrease of development predictabilityIncrease of confidence that a system is acceptable of its intended purposeIncrease of savings for time and money

A subtle defect can have a significant impact.

5

Key Components to Testing

Test PlanTest Cases and ScriptsTest Traceability

6

Where is the Duplicate WorkFunctional decompositions for a project

Function Point CountingTestingWork Breakdown Structures

Information for testing and counting are similar once both sides are understoodIf trained, testers have insight to the information needed for countingTraceability could be created which included function point transactions

7

Language Gaps

External Inquiries (EQs)External Outputs (EOs)External Inputs (EIs)Data Element Types (DETs)File Types Referenced (FTRs)Record Element Types (RETs)External Interface Files (EIFs)Internal Logical Files (ILFs)

Tester LingoFunction Point LingoTarget Tables for data validation testing

Referenced or source tables for data validation testingData dependencies

Data Sources

Data fields used (also triggers & messages)

Data maintenance transactions

Reporting or control population

Reporting or control population

8

How to Approach Alignment

Two Highly Recommended Test ConceptsSmart Numbering ScriptsTest Traceability

Not all test items will be counted

9

Numbering and Tracing

02.201.02 – Create Replenishment Order

FR 02 – Replenishment Order

02.201.01 – Create Standard Order

FR 01 – Standard OrderBR01 – Create OrderTest ScriptFunctional RequirementBusiness Requirement

………301. GUI302. Key Strokes303. Title Bar304. Links305. Screen

201. Add202. Delete203. Edit204. Print205. Report206. Display207. Error Handling

101. Log on102. Log off103. Verify Profile104. Registration105. Setup Security

Procedure………03. Navigation02. Business Function01. SecurityClass

10

ExampleApplication that reports on test incidents which have become questionably aged for their severity category

Boundary DecisionsData Function TypesTransactional Function Types

11

Boundary Decisions

Local Aged Database> IncidentDownload> TimeStamps

Aged Incident ApplicationReportingAged Incident

Export

Aged ProjectExport

Individual AgedIncident Report

Online AgedIncident Report

Online AgedProject Report

Data SourcesTest Tracking Database> IncidentReports

Project Information Database> Projects

Aged Reporting Support Database> ActiveStatus> InactiveStatus> IncidentAgeLimits> ReportText

Application Boundary

12

Data Function TypesRequired information for testing purposes:

Where is the data located?How is the data loaded?Are there data interdependencies?What is the data used for?

13

Data Function Types

ActiveStatusInactiveStatus

IncidentAgeLimitsReportText

ProjectsIncidentReports

IncidentDownloadTimeStamps

Data Sources

External to systemNot maintained by another application

External to systemMaintained by users in other applications

Maintained by users in this application

Collected Test Info

X

EIFs

ILFs

14

EIF InformationData Source: Project Information Database

Table: Projects

There are more fields on the table, but the system only uses these three (3).

Data Source: Test Tracking Database

Table: IncidentReports

There are more fields on the table, but the system only uses these thirteen (13).

15

ILF InformationData Source: Local Aged Database

Table:IncidentDownload Table: TimeStamps

16

Data Summary

7Low1 / 2ILFYESTimeStamps7Low1 / 21ILFYESIncidentDownload5Low1 / 13EIFNOIncidentReports5Low1 / 3EIFNOProjects

--------- / ------NOReportText--------- / ------NOIncidentAgeLimits--------- / ------NOInactiveStatus

Function Points

ComplexityRETs/DETs

ILF/EIF

Data Validation

Testing

Data Sources

--------- / ------NOActiveStatus

Information Needed For TestingShared NeedsFor Function

Point Counting

Counting SpecificInformation

17

Transaction Function TypesBusiness RequirementsGUI Screen ShotBackground/AnalysisDual Perspectives of Testers and CountersSummary

18

Business Requirement BR 01BR 01 - The application should build a table in a local database.

FR 01.01 - Must interface with the Lotus Notes Test Tracking Database to download 13 pieces of informationFR 01.02 – Must interface with the Project Information Database to determine the Test Lead for each record.FR 01.03 – Must calculate the age of each incident, then interface with the Aged Reporting Support Database to determine what the maximum allowable age is for each records’ Severity, then determine which (if any) rule it has violated and create a reason string for any violations. FR 01.04 – Must create three fields to designate sending messages about the incident to either the creator, the assigned responsible, or the test lead.FR 01.05 – Must record the time the data was last updated, and display it to the user.FR 01.06 – Should default to display the Aged Incident Grid after data has been updated.

19

GUI Screen Shot for BR 01

20

Background/Analysis for BR 01The ActiveStatus, InactiveStatus, and IncidentAgeLimits tables will be referencedThe Projects and IncidentReports tables will have data obtained from themThe IncidentDownload and TimeStamps tables will be updatedProcess is initiated by clicking a buttonThere is a visual representation of the time and date the data was obtainedThere is one process with no choicesThe Aged Incident Grid will be handled separately, because it is only run here as an assumption of need

21

Dual Perspectives for BR 01

Nothing crossing boundary so no additional DETs

3 “Send To” fields for involved personnel will be defaulted to ‘No’

No additional FTRs since they are not EIFs or ILFs, the calculations are not crossing boundary so no additional DETs

ActiveStatus, InactiveStatus, and IncidentAgeLimits (no maintenance app) are referenced for calculations

2 FTRs, 14 DETs, the data on the ILFs and EIFs are the same so no additional DETs

Obtaining data from 2 tables, 13 pieces of data from IncidentReportsand 1 piece from Projects

Primary intent is to maintain two ILFs (EI),2 FTRs mentioned, Display 1 DET from TimeStamps

Updating 2 tables (IncidentDownloadand TimeStamps) displaying data from one (TimeStamps)

There is one elementary processButton Click is 1 DET for initiation

Click button everything happensWhat a Counter would seeWhat a Tester would see

22

Summary for BR 01

---------/------(See BR 03)FR 06^ ^ ^^ ^ ^ ^ ^^ ^ ^^ ^ ^^ ^ ^ ^ ^FR 05^ ^ ^^ ^ ^ ^ ^^ ^ ^^ ^ ^^ ^ ^ ^ ^FR 04^ ^ ^^ ^ ^ ^ ^^ ^ ^^ ^ ^^ ^ ^ ^ ^FR 03^ ^ ^^ ^ ^ ^ ^^ ^ ^^ ^ ^^ ^ ^ ^ ^FR 02

6High4 / 16EI04.403.01 – Import Incident Data

FR 01BR 01

Function Points

ComplexityFTR/DET

EI/EO/EQ

ScriptFun. Req.

Bus. Req.

Information Needed for TestingShared Needsfor Function

Point CountingCounting Specific

23

Business Requirement BR 02BR 02 – The user should be able to pull up the rules for aged incidents to view them at any time during use of the application.

24

GUI Screen Shot for BR 02

25

Background/Analysis for BR 02A button will be clicked to display the aging rulesThe rules are contained in the table IncidentAgeLimits

26

Dual Perspectives for BR 02

The data is coming from a table which is neither an ILF nor an EIF, so they could just as easily be hard coded. This will not be included in the function point count.

The information is contained in the IncidentAgeLimits table (not maintained by an application so no maintenance testing). A query will have to be written to test what is shown on the rules window

Navigation… possibly to initiate an elementary process???

Click button to see what the rules areWhat a Counter would seeWhat a Tester would see

27

Summary for BR 02

---------/------04.403.02 – Display Aging Rules

NABR 02

Function Points

ComplexityFTR/DET

EI/EO/EQ

ScriptFun. Req.

Bus. Req.

Information Needed for TestingShared Needsfor Function

Point CountingCounting Specific

28

Business Requirement BR 03BR 03 – The application should be able to display a report showing Questionably Aged Incidents to show reports that may need review.

FR 03.01 – Only incident reports with aged violations will be shownFR 03.02 – The following fields should be shown on the report: Project ID,Project Name, Reason for Violation, Incident Number, Incident Description, Severity, Status, Age (in days), Test Lead, Creator, and Assigned To. The user should be able to select which of these fields are included in the report. A count of records should also be shown.FR 03.03 – The user should be able to filter the report two different ways.

• A – Select a person’s name to view a list of incidents where that person was the Test Lead, Creator, or Assigned To. The list of names should only contain choices that will return data.

• B – Select any combination of the following: Project ID, Creator, Test Lead, or Assigned To. The lists should only contain choices that will return data.

FR 03.04 – The user should be able to export the report to MS Word.

29

GUI Screen Shot for BR 03 (1 of 2)

30

GUI Screen Shot for BR 03 (2 of 2)

31

Background/Analysis for BR 03The user can generate the full report by clicking the [Reload Questionable Aged Incident] buttonThe user can generate a filtered report by clicking the [Update Questionably Aged Incident List]The report can be exported to MS WordGeneral Filter applies a name condition to the Created By, Test Lead, and Assigned To attributesDetailed Filter applies each name condition individually and also includes a Project ID filterThere is a calculation for the online report to show the record countThe user can decide which of the 11 fields to show on the reportAll data comes from the IncidentDownload table

32

Dual Perspectives for BR 03

There is 1 FTRAll data comes from one table

Same number of DETs except for 1 for the record count. Since the calculation is gone, it is an EQ

The export report in MS Word is the same except for the count

1 DET, plus a calculation to make it an EOThere is a record count

1 DET for initiationThere are two buttons to run report

There is only one online report that shows 11 possible fields, the user can input 4 filter options but they are also shown on report, 11 show/no show options (22 DETs)

The online report can be run full, with a general filter, or a detailed filter; and showing specific fields

What a Counter would seeWhat a Tester would see

33

Summary for BR 03

4Average1 / 23EQ05.503.01 – Export Incident Rpt to Word

FR 04

^ ^ ^^ ^ ^ ^ ^^ ^ ^^ ^ ^02.205.03 – Aged Incident (Det Filter)

FR 03

^ ^ ^^ ^ ^ ^ ^^ ^ ^^ ^ ^02.205.02 – Aged Incident (Gen Filter)

FR 02

5Average1 / 24EO02.205.01 – Aged Incident (Unfiltered)

FR 01BR 03

Function Points

ComplexityFTR/DET

EI/EO/EQ

ScriptFun. Req.

Bus. Req.

Information Needed for TestingShared Needsfor Function

Point CountingCounting Specific

34

Other Business Requirements

This example contains two additional Business Requirements. They are also covered in the accompanying paper (“Aligning Function Point Counting and Test Planning”), which should be included with this presentation on the conference CD.

35

Other Items to Test and CountGeneral navigation and Controls…

Where do you include these…?It depends on organizational decisions:

•With an associated business function

•Grouped together

General navigation NO | Population of controls MAYBEIt all has to be tested, but not all of it is counted.

36

Project Is Over… Start the Count

37

Project Is Over… Start the Count

Unadjusted Function Point Count = 72

38

Additional AdvantageFunction Point based metrics for testing

Function Points TestedFunction Points Not TestedFunction Points PassedFunction Points Failed

39

End of Presentation

QUESTIONS???