Aligning Function Point Counting and Test Planning

Transcription

1 Aligning Function Point Counting and Test Planning Chris Francis, CSTE Senior Consultant Nestlé Purina Petcare Company Checkerboard Square St. Louis, MO

2 Content Brief Background on Testing Similarities Between Counting and Testing Example 2

3 What is Testing? Operating a system or application under controlled conditions and evaluating the results Includes both normal and abnormal operating conditions Oriented toward detection A process to measure software quality An input to the judgment of risk 3

4 Why Test? A subtle defect can have a significant impact. Reduction of problems occurring in production systems Reduction of software support costs Increase of development predictability Increase of confidence that a system is acceptable of its intended purpose Increase of savings for time and money 4

5 Key Components to Testing Test Plan Test Cases and Scripts Test Traceability 5

6 Where is the Duplicate Work Functional decompositions for a project Function Point Counting Testing Work Breakdown Structures Information for testing and counting are similar once both sides are understood If trained, testers have insight to the information needed for counting Traceability could be created which included function point transactions 6

7 Language Gaps Function Point Lingo Internal Logical Files (ILFs) External Interface Files (EIFs) Record Element Types (RETs) File Types Referenced (FTRs) Data Element Types (DETs) External Inputs (EIs) External Outputs (EOs) External Inquiries (EQs) Tester Lingo Target Tables for data validation testing Referenced or source tables for data validation testing Data dependencies Data Sources Data fields used (also triggers & messages) Data maintenance transactions Reporting or control population Reporting or control population 7

8 How to Approach Alignment Two Highly Recommended Test Concepts Smart Numbering Scripts Test Traceability Not all test items will be counted 8

9 Numbering and Tracing Class 01. Security 02. Business Function 03. Navigation Procedure 101. Log on 201. Add 301. GUI 102. Log off 202. Delete 302. Key Strokes 103. Verify Profile 203. Edit 303. Title Bar 104. Registration 204. Print 304. Links 105. Setup Security 205. Report 305. Screen 206. Display 207. Error Handling Business Requirement BR01 Create Order Functional Requirement FR 01 Standard Order FR 02 Replenishment Order Test Script Create Standard Order Create Replenishment Order 9

10 Example Application that reports on test incidents which have become questionably aged for their severity category Boundary Decisions Data Function Types Transactional Function Types 10

11 Boundary Decisions Data Sources Test Tracking Database > IncidentReports Project Information Database > Projects Aged Reporting Support Database > ActiveStatus > InactiveStatus > IncidentAgeLimits > ReportText Application Boundary Local Aged Database > IncidentDownload > TimeStamps Reporting Aged Incident Application Aged Incident Export Aged Project Export Online Aged Incident Report Online Aged Project Report Individual Aged Incident Report 11

12 Data Function Types Required information for testing purposes: Where is the data located? How is the data loaded? Are there data interdependencies? What is the data used for? 12

13 Data Function Types Data Sources ActiveStatus InactiveStatus IncidentAgeLimits ReportText Projects IncidentReports IncidentDownload TimeStamps Collected Test Info External to system Not maintained by another application External to system Maintained by users in other applications Maintained by users in this application X EIFs ILFs 13

14 EIF Information Data Source: Project Information Database Table: Projects Data Source: Test Tracking Database Table: IncidentReports There are more fields on the table, but the system only uses these three (3). There are more fields on the table, but the system only uses these thirteen (13). 14

15 ILF Information Data Source: Local Aged Database Table:IncidentDownload Table: TimeStamps 15

16 Data Summary Information Needed For Testing Data Sources ActiveStatus InactiveStatus IncidentAgeLimits ReportText Data Validation Testing NO NO NO NO Shared Needs For Function Point Counting ILF/ EIF RETs/ DETs --- / / / / --- Counting Specific Information Complexity Function Points Projects NO EIF 1 / 3 Low 5 IncidentReports NO EIF 1 / 13 Low 5 IncidentDownload YES ILF 1 / 21 Low 7 TimeStamps YES ILF 1 / 2 Low 7 16

17 Transaction Function Types Business Requirements GUI Screen Shot Background/Analysis Dual Perspectives of Testers and Counters Summary 17

18 Business Requirement BR 01 BR 01 - The application should build a table in a local database. FR Must interface with the Lotus Notes Test Tracking Database to download 13 pieces of information FR Must interface with the Project Information Database to determine the Test Lead for each record. FR 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 Must create three fields to designate sending messages about the incident to either the creator, the assigned responsible, or the test lead. FR Must record the time the data was last updated, and display it to the user. FR Should default to display the Aged Incident Grid after data has been updated. 18

19 GUI Screen Shot for BR 01 19

20 Background/Analysis for BR 01 The ActiveStatus, InactiveStatus, and IncidentAgeLimits tables will be referenced The Projects and IncidentReports tables will have data obtained from them The IncidentDownload and TimeStamps tables will be updated Process is initiated by clicking a button There is a visual representation of the time and date the data was obtained There is one process with no choices The Aged Incident Grid will be handled separately, because it is only run here as an assumption of need 20

21 Dual Perspectives for BR 01 What a Tester would see Click button everything happens Updating 2 tables (IncidentDownload and TimeStamps) displaying data from one (TimeStamps) Obtaining data from 2 tables, 13 pieces of data from IncidentReports and 1 piece from Projects ActiveStatus, InactiveStatus, and IncidentAgeLimits (no maintenance app) are referenced for calculations 3 Send To fields for involved personnel will be defaulted to No What a Counter would see There is one elementary process Button Click is 1 DET for initiation Primary intent is to maintain two ILFs (EI), 2 FTRs mentioned, Display 1 DET from TimeStamps 2 FTRs, 14 DETs, the data on the ILFs and EIFs are the same so no additional DETs No additional FTRs since they are not EIFs or ILFs, the calculations are not crossing boundary so no additional DETs Nothing crossing boundary so no additional DETs 21

22 Summary for BR 01 Information Needed for Testing Shared Needs for Function Point Counting Counting Specific Bus. Req. Fun. Req. Script EI/ EO/ FTR/ DET Complexity Function Points EQ BR 01 FR Import Incident Data EI 4 / 16 High 6 FR 02 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ FR 03 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ FR 04 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ FR 05 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ FR 06 (See BR 03) /

23 Business Requirement BR 02 BR 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. 23

24 GUI Screen Shot for BR 02 24

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

26 Dual Perspectives for BR 02 What a Tester would see Click button to see what the rules are 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 What a Counter would see Navigation possibly to initiate an elementary process??? 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. 26

27 Summary for BR 02 Information Needed for Testing Shared Needs for Function Point Counting Counting Specific Bus. Req. Fun. Req. Script EI/ EO/ FTR/ DET Complexity Function Points EQ BR 02 NA Display Aging Rules /

28 Business Requirement BR 03 BR 03 The application should be able to display a report showing Questionably Aged Incidents to show reports that may need review. FR Only incident reports with aged violations will be shown FR 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 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 The user should be able to export the report to MS Word. 28

29 GUI Screen Shot for BR 03 (1 of 2) 29

30 GUI Screen Shot for BR 03 (2 of 2) 30

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

32 Dual Perspectives for BR 03 What a Tester would see The online report can be run full, with a general filter, or a detailed filter; and showing specific fields There are two buttons to run report There is a record count The export report in MS Word is the same except for the count All data comes from one table What a Counter would see 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) 1 DET for initiation 1 DET, plus a calculation to make it an EO Same number of DETs except for 1 for the record count. Since the calculation is gone, it is an EQ There is 1 FTR 32

33 Summary for BR 03 Information Needed for Testing Shared Needs for Function Point Counting Counting Specific Bus. Req. Fun. Req. Script EI/ EO/ FTR/ DET Complexity Function Points EQ BR 03 FR Aged Incident (Unfiltered) EO 1 / 24 Average 5 FR Aged Incident (Gen Filter) ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ FR Aged Incident (Det Filter) ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ FR Export Incident Rpt to Word EQ 1 / 23 Average 4 33

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. 34

35 Other Items to Test and Count General navigation and Controls General navigation NO Population of controls MAYBE It all has to be tested, but not all of it is counted. Where do you include these? It depends on organizational decisions: With an associated business function Grouped together 35

36 Project Is Over Start the Count 36

37 Project Is Over Start the Count Unadjusted Function Point Count = 72 37

38 Additional Advantage Function Point based metrics for testing Function Points Tested Function Points Not Tested Function Points Passed Function Points Failed 38

39 End of Presentation QUESTIONS??? 39