ppt - aligning function point counting and test planning · 1 aligning function point counting and...
TRANSCRIPT
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???