Software Test Plan. Basic Order Tracking System. Digital Publications LLC. Document ID: BOTS-CUST-STP Version: / 44.

Transcription

1 Basic Order Tracking System Prepared For: Prepared By: Highland Office Supply John Zoltai Digital Publications LLC Document ID: Version: 1.0 Planning Installation & Acceptance Integration & Test Requirements Definition Design Development 1 / 44

2 Copyright 2005 Digital Publications LLC 2

3 TABLE OF CONTENTS INTRODUCTION... 5 PURPOSE... 5 SCOPE... 5 METHODOLOGY... 5 TEST PROCEDURES ACCEPTANCE TEST PROCEDURE REGRESSION TEST PROCEDURE DATABASE ENGINE VALIDATION TEST CASES TEST CASE 1: DATABASE ENGINE DICTIONARY AND ACCESS TEST CASE 2: DATABASE ENGINE VALIDATION DATABASE TRIGGERS TEST CASES TEST CASE 3: CUSTOMER TRIGGERS TEST CASE 4: DEMOGRAPHIC TRIGGERS CUSTOMER DATA AREA TEST CASES TEST CASE 5: CUSTOMER DATA AREA SELECTION & TOP TEST CASE 6: CUSTOMER SEARCHES TEST CASE 7: CUSTOMER SUMMARY LISTING TEST CASE 8: CUSTOMER DETAIL DISPLAY TEST CASE 9: CUSTOMER REPORTS TEST CASE 10: CUSTOMER OPERATIONS DEMOGRAPHICS DATA AREA TEST CASES TEST CASE 11: DEMOGRAPHICS SELECTION & TOP TEST CASE 12: DEMOGRAPHIC SEARCHES TEST CASE 13: DEMOGRAPHIC SUMMARY LISTING TEST CASE 14: DEMOGRAPHIC DETAIL DISPLAY TEST CASE 15: DEMOGRAPHIC REPORTS TEST CASE 16: DEMOGRAPHIC OPERATIONS ANALYSIS LISTING

4 GLOSSARY OF PROJECT-SPECIFIC TERMS Glossary of Software Engineering Terms Glossary of Project- Specific Terms A standard Glossary of Software Engineering Terms is maintained online. Terms specific to this project are maintained below. A common Glossary of Project-Specific Terms is maintained on the project Web site. 4

5 INTRODUCTION This is the Software Test Plan (STP) for the Customer Management (BOTS- CUST) database application. PURPOSE The purpose of this test plan is to validate the structure and feature set of the software defined in the BOTS-CUST Design Document and associated Physical Database Description. A test plan defines what will be tested and how, in order to ensure that the software is complete and correctly implemented to specifications. SCOPE The BOTS-CUST application has two primary components: A database engine and an end-user interface. This test plan focuses on validating the database structure, database engine performance, and the feature set presented by the end user interface. METHODOLOGY The organization of this test plan is based on three key concepts: Test Classes, Test Procedures, and Test Cases. Basically, test cases belong to one of three test classes and each test case may be utilized by one or more test procedures, as shown in the diagram below. 5

6 Application Usage Validation Test Classes Application Internal Validation Database Engine Validation TEST CLASSES The three test classes include black-box testing, white-box testing, and database engine validation. Any single test case will belong to only one of these three test classes. BLACK-BOX TESTING Test cases of this class are generally performed by knowledgeable end-users and are used to validate the features that are presented to the end-user via the user interface. In simple terms, these test cases validate the usage of the features available to the end-user, treating the software as a black box, because the internal functionality of the software is not visible. Test cases of this class are sometimes referred to as external testing. Black-box tests fall into six categories: 1. Module entry & flow 2. Precondition business rules 3. Initialization business rules 4. Interaction business rules 5. Conclusion business rules 6. Performance testing 6

7 WHITE-BOX TESTING Test cases of this class are generally performed by members of the development team and are used to validate the internal operations of the software that are visible to the developer. To accomplish this, members of the development team use special tools, such as a debugger, to validate the internal operation of the software. Test cases of this class are sometimes referred to as glass-box testing (because you can see inside the software) or internal testing. White-box tests fall into two categories: 1. Database engine validation 2. Access control validation Database Engine Validation Test cases of this class are generally performed by members of the development team and are used to validate that the structure of the database as implemented matches the design as specified. This class of tests also validates that the performance of the database engine meets the constraints identified in the design document. To validate the structure, members of the development team use the administrative interfaces of the database engine to compare stored dictionary information with the physical database description developed during the design stage of this project. To validate database engine performance, testers may use specialized software to perform load testing (simultaneous users) and volume testing (database capacity) on a database server configured to match the production server. Access Control Validation Access control is validated by examining the user roles defined in the database engine and comparing them to the roles defined in the PDD, and then examining the table access restrictions to validate they are associated with the proper roles. This is typically a white-box test conducted by a database administrator using a standard engine administration tool. TEST PROCEDURES This test plan utilizes two classes of test procedures: 1. Acceptance testing 2. Regression testing One or more of these test procedures may utilize any single test case. 7

8 ACCEPTANCE TESTING The acceptance test procedure uses a "lightweight" set of test cases intended to validate that the software is functioning correctly at the top level. Acceptance tests are used for two reasons: Acceptance into testing, and acceptance into production. When the application (or a portion thereof) is deemed ready for test by the development team, the acceptance test procedure is run to ensure that the test instances of the database server and application software are basically functional. If the software fails to pass this limited set of tests, the software is returned to the development team for correction. If the software passes the acceptance tests, it is then subjected to comprehensive test procedures as described below. Once the application has passed the comprehensive test procedure, a production instance of the application is installed. The acceptance test procedure is run once again to ensure that the software was properly migrated, without forcing a repetition of the comprehensive test procedure. Successful completion of the acceptance test procedure on the production instance of the application, coupled with the documentation showing that the software has previously passed the comprehensive test procedure, serves as the basis for acceptance of the software by the customer. REGRESSION TESTING The regression test procedure makes use of test cases that perform a detailed examination of the software and database engine. A regression test is a comprehensive test, incorporating all known features of the application. The objective of a regression test procedure is to examine everything in detail. During production, the occasional bug may be discovered. Regression tests are also designed to ensure that all reported bugs have been fixed in all subsequent releases of the software. This becomes especially important when developers other than the original team are performing bug fixes. Certain test cases are specifically designed to make sure a bug has been fixed. The regression test procedure also uses test cases involving functions and features that may have been impacted by the bug fixing process. TEST CASES Each test case describes a specific set of goals designed to validate the correct operation of a specific subset of the software. Test cases come in a variety of forms, each specific to the task at hand. In general, each test case is written specifically for end-users and developers that are familiar with the application. 8

9 CRITICAL SUCCESS FACTOR: APPLICATION FAMILIARITY Familiarity with the application under test is the single critical success factor of this test plan, as it allows the specification of test cases that are focused on testing a specific area of the application, rather than broad spectrum test cases that walk a tester through, step-by-step, from the top of the application to the desired test areas. For example, when a test case specifies the examination of a specific data entry screen, it does not provide a step-by-step checklist to arrive at that screen. Instead, the tester is expected to be familiar enough with the application that accessing the screen is not a mystery. This allows each test case to be tightly focused on a specific feature set. PERSONNEL ROLES AND RESPONSIBILITIES Personnel responsible for ensuring that testing activities take place are the Primary End-user Representative (PER) and the Primary Developer Representative (PDR). Together, the PER and the PDR are responsible for ensuring that appropriate end-user and developer personnel conduct the testing activities. The PER and the PDR are also responsible for coordinating the responses to any test incident reports that arise. TEST RESULTS REPORTING Test results are reported on a case-by-case basis. The functional area being examined by a test case either performs as expected or not. Test results are reported to the PER or PDR as appropriate, generally via electronic mail with attachments of the appropriate form. Successful completion of a test is reported via a Test Completion Report form, available at Any test failure is reported via a Test Incident Report form, available at: The test incident report form is used to record not only the details of the failure, but also the actions taken to correct the problem. TEST ENVIRONMENT The hardware and software environment for both database server and end-user workstations shall closely replicate the actual production environment: 9

10 DATABASE SERVER The anticipated database server environment consists of: DBServerDescription END-USER WORKSTATIONS The anticipated end-user workstation environment consists of: WorkstationDescription DELIVERABLES A summary of successful test reports for test cases associated with the comprehensive test procedure and regression test procedure (if appropriate) are incorporated into the acceptance plan during the integration & test stage. Once the application has been migrated to production, the acceptance test procedure is run once again, and if successful, recorded as defined by the acceptance plan. At this point, sufficient evidence exists to justify the acceptance of the software by the customer. 10

11 TEST PROCEDURES Each test procedure consists of a series of defined test cases, falling under one of the three major test classes. The following test procedures are defined under this plan: ACCEPTANCE TEST PROCEDURE BLACK-BOX TESTING Test Case 5: Customer Data Area Selection & Top Test Case 7: Customer Summary Listing Test Case 11: Demographics Selection & Top Test Case 13: Demographic Summary Listing REGRESSION TEST PROCEDURE DATABASE ENGINE VALIDATION Test Case 1: Database engine data dictionary and access roles. Test Case 2: Database engine performance. BLACK-BOX TESTING Test Case 5: Customer Data Area Selection & Top Test Case 6: Customer Searches Test Case 7: Customer Summary Listing Test Case 8: Customer Detail Display Test Case 9: Customer Reports Test Case 10: Customer Operations Test Case 11: Demographics Selection & Top Test Case 12: Demographic Searches Test Case 13: Demographic Summary Listing Test Case 14: Demographic Detail Display 11

12 Test Case 15: Demographic Reports Test Case 16: Demographic Operations WHITE-BOX TESTING Test Case 3: Customer Triggers Test Case 4: Demographic Triggers 12

13 DATABASE ENGINE VALIDATION TEST CASES TEST CASE 1: DATABASE ENGINE DICTIONARY AND ACCESS Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies DB Engine Validation. Database engine data dictionary and access roles. Perform a dictionary comparison to assure that the database engine data dictionary matches design specifications. BOTS-PDD: Physical Database Description (PDD). Database engine data dictionary or catalog output. Client and server hardware + software connected via network, as specified in BOTS-CUST-SDD: Design Document, Design Constraints Compliance. Database Administrator access to the database engine is required to be able to perform this test. A correctly structured data dictionary is essential for virtually all test cases. That s why we re checking it first. TEST STEPS Validate each of the following statements: T1a-D1 T T1b-D1 T1c-D1 T1d-D2 T1e-D2a T1f-D3 All tables described in the PDD are named correctly in the database engine. All field definitions and constraints in the database engine match the Data Dictionary specifications in the PDD. All roles defined in the Access Control Matrix of the PDD are accurately implemented in the database engine. The system restricts access to those users who have been granted privileges to access this component by the database administrator. The system enforces access rights according to membership in one or more user roles according to the Access Control Matrix in the Physical Database Description. It is not necessary for this component to encrypt the information passing between users and the database server. Conversely, if encryption is a default operation of the implemented database platform, encryption does not have to be deactivated as a prerequisite for acceptance by Highland Office Supply. 13

14 TEST CASE 2: DATABASE ENGINE VALIDATION Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies DB Engine Validation. Database engine performance. This is a performance test of a fully loaded database engine to validate that engine performance meets design constraints. BOTS-CUST-LDD: Logical Database Description and BOTS- CUST-SRD: Requirements Document, Design Constraints paragraphs. Timing results. Client and server hardware + software connected via network, as specified in BOTS-CUST-SDD: Design Document, Design Constraints Compliance paragraphs. Custom developed scripts will need to have access to the database engine to be able to perform this test. TEST STEPS Validate each of the following statements: T2a-D1 T T2b-D1 T2c-D1 T2d-D1 T2e-D1 The database engine has enough records loaded to meet the Scalability design constraint described in BOTS-CUST-SRD, based on first year load figures for each major entity described in BOTS-CUST-LDD. The database engine has enough simulated clients connected to meet the Multiple Users and Scalability design constraints described in BOTS- CUST-SRD. The database engine meets or exceeds the Summary Listing Performance constraint at full load. The database engine meets or exceeds the Data Entry & Detail Display Performance constraint at full load. The database engine meets or exceeds the Report Generation Performance constraint at full load. 14

15 DATABASE TRIGGERS TEST CASES TEST CASE 3: CUSTOMER TRIGGERS Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies White Box Testing Customers Table database triggers Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in BOTS-CUST-SDD: Design Document, Design Constraints Compliance paragraphs. Using a database direct table manipulation tool, directly insert/update/delete records as appropriate to evaluate the following test conditions. TEST STEPS Validate each of the following statements: 15

16 T3a-D4 T3b-D4a T3c-D4b T3d-D4c T3e-D4d T3f-D4e T3g-D4f T3h-D4g T3i-D4h T3j-D4i T3k-D4j T3l-D4k Customer_ID is a unique field. On insert, if Customer_ID is null, Customer_ID is automatically populated with a unique number by the database. Billing_Addr1 cannot be null. Billing_City cannot be null. Billing_State cannot be null. Billing_Zip cannot be null. Contact_Name cannot be null. Phone cannot be null. Shipping_Addr1 cannot be null. Shipping_City cannot be null. Shipping_State cannot be null. Shipping_Zip cannot be null. 16

17 TEST CASE 4: DEMOGRAPHIC TRIGGERS Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies White Box Testing Demographics Table database triggers Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in BOTS-CUST-SDD: Design Document, Design Constraints Compliance paragraphs. Using a database direct table manipulation tool, directly insert/update/delete records as appropriate to evaluate the following test conditions. TEST STEPS Validate each of the following statements: T4-D5 T T4a-D5a T4b-D5b Demog_ID is a unique field. On insert, if Demog_ID is null, Demog_ID is automatically populated with a unique number by the database. Demog_Name cannot be null. 17

18 CUSTOMER DATA AREA TEST CASES TEST CASE 5: CUSTOMER DATA AREA SELECTION & TOP Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing CustomerTop Page Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in BOTS-CUST-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: T5-D6 T T5a-D6a T5b-D6b The Customer data area provides the ability to enter, update, and maintain information in the Customer and CustDemogs tables. A link to the Customer data area top page appears in the Operational Data Areas section of the application top page. The system restricts user access to this Data Area according to membership in the user roles described in the Access Control Matrix in the Physical Database Description. 18

19 DATA AREA TOP T5c-D7 When the user selects the customer data area link from the Application Top page, the Customer Data Area page is presented. This page allows the user to choose to perform a predefined search, develop an ad hoc search, or add new records, has shown below. The data area top page also provides links to separate reporting and operations pages. Form CustomerTop is used. The core business rules for this form are the same as for the Data Area Top page described in the Core Functions component. Additional business rules for this form are described below. CustomerTop PRECONDITIONS None INITIALIZATION RULES T5d-D7a T T5e-D7b T5f-D7c T5g-D7d T5h-D7e A Quick Search link and description is installed in the Pre-defined search section of this form. A Back orders search link and description is installed in the Pre-defined search section of this form. A Product purchasers search link and description is installed in the Predefined search section of this form. An Active customers search link and description is installed in the Predefined search section of this form. An Inactive customers search link and description is installed in the Predefined search section of this form. 19

20 INTERACTION RULES T5i-D7f T T5j-D7g T5k-D7h T5l-D7i T5m-D7k Clicking on the Quick search link initiates a Quick Search as described in the searches section below. Clicking on the Back orders link initiates the pre-defined search as described in the searches section below. Clicking on the Product purchasers link initiates the pre-defined search as described in the searches section below. Clicking on the Active customers search link initiates the pre-defined search as described in the searches section below. Clicking on the Inactive customers search link initiates the pre-defined search as described in the searches section below. CONCLUSION RULES None 20

21 TEST CASE 6: CUSTOMER SEARCHES Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing CustomerTop Page, Searches Section Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in BOTS-CUST-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: QUICK SEARCH T6-D8 A dialog is presented consisting of a popup list of indexed fields for the main table of the data area, along with a popup list of comparison operators, an enterable Value field, and Submit/Cancel buttons. Form Quick.Qry is used: The user is allowed to select one field, one comparison operator, and enter a value to be compared against. Clicking the Submit button executes the search as constructed by the user. The result set is presented in the summary listing. Clicking the Cancel button returns to the CustomerTop page. BACK ORDERS T6a-D9 T The OrderLines table is searched for records with OrderLines.Back_Ordered fields with nonzero dates. The result set is joined to the Orders table, and the subsequent set is joined to the Customers table. The final result set is presented in the summary listing. 21

22 PRODUCT PURCHASERS T6b-D10 A dialog is presented consisting of a list of Product_ID and Product_Name fields, along with Submit/Cancel buttons. Form ProdPurch.Qry is used: The user may select one or more products in the list. When the Submit button is pressed, the OrderLines table is searched for records where OrderLines.Product_ID is among the products selected in the dialog. The result set is joined to the Orders table, and the subsequent set is joined to the Customers table. The final result set is presented in the summary listing. ACTIVE CUSTOMERS T6c-D11 A dialog is presented consisting of Start Date and End Date enterable variables, and Submit/Cancel buttons. Form ActiveCust.Qry is used: Both Start and End Date variables must be filled in by the user before the Submit button will function. When the Submit button is pressed, the Orders table is searched for records where Orders.Order_Date falls on or between the Start and End date variables. The result set is joined to the Customers table. The final result set is presented in the summary listing. 22

23 INACTIVE CUSTOMERS T6d-D12 A dialog is presented consisting of Start Date and End Date enterable variables, and Submit/Cancel buttons. Form InactiveCust.Qry is used: Both Start and End Date variables must be filled in by the user before Submit button will function. When the Submit button is pressed, the Orders table is searched for records where Orders.Order_Date DOES NOT FALL on or between the Start and End date variables. The result set is joined to the Customers table. The final result set is presented in the summary listing. 23

24 TEST CASE 7: CUSTOMER SUMMARY LISTING Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing Customers.L Page Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in BOTS-CUST-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: T7-D13 After completing a search or add records operation, the user is presented with a summary listing of records that match the search criteria, or the newly entered records. Form Customers.L is used. The business rules for this form are the same as for the Summary Listing page described in the Core Functions component. Customers.L 24

25 TEST CASE 8: CUSTOMER DETAIL DISPLAY Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing Customers.D Page Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in BOTS-CUST-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: T8-D14 The detail display for each data area is presented when a user clicks on a record link from a summary page, or on a Next / Previous / First / Last button on another record. Form Customers.D is used. Core business rules for this form are the same as for the Detail Display page described in the Core Functions component, as well as the field defaults, formats, ranges, and special rules described in the Data Dictionary. Specific business rules for this form are described below. 25

26 Customers.D PRECONDITIONS None INITIALIZATION RULES T8a-D14a T T8b-D14b T8c-D14c If a new record is being added, the Customer ID is automatically assigned by the system. All other fields are either empty or set to their default value, as appropriate. If an existing record is being displayed, the Customer ID is non-enterable, and the Demographics list is filled with related Demog_Names from the Demographics table. Transaction processing and associated record locking is initiated for this form. 26

27 INTERACTION RULES T8d-D14d T T8e-D14e T8f-D14f T8g-D14g T8h-D14h T8i-D14i When Shipping_Addr_1 is modified, AND Billing_Addr_1 is empty, copy the entered contents of Shipping_Addr_1 to Billing_Addr_1. When Shipping_Addr_2 is modified, AND Billing_Addr_2 is empty, copy the entered contents of Shipping_Addr_2 to Billing_Addr_2. When Shipping_City is modified, AND Billing_City is empty, copy the entered contents of Shipping_City to Billing_City. When Shipping_State is modified, AND Billing_ State is empty, copy the entered contents of Shipping_ State to Billing_ State. When Shipping_Zip is modified, AND Billing_ Zip is empty, copy the entered contents of Shipping_ Zip to Billing_ Zip. When the button next to the Demographics list is pressed, a dialog is presented with a list of available Demog_Name values from the Demographics table, and submit/cancel buttons: T8j-D14j When the user selects an item on the list and presses the submit button, the user is returned to the Customers.D page with the new demographic value inserted into the sorted Demographics list. Pressing the cancel button closes the dialog with no further action. When a Demographic item in the Demographics list is selected, AND the button next to the Demographics list is pressed, the Demographic item is removed from the list. CONCLUSION RULES T8k-D14k T T8l-D14l When the user presses the Submit button, the current set of transactions are committed to the database, associated records are unlocked, and the user is returned to the summary listing. When the user presses the Cancel button, the current set of transactions are cancelled, associated records are unlocked, and the user is returned to the summary listing. 27

28 TEST CASE 9: CUSTOMER REPORTS Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing Customers.Rpt and associated reports Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in PROJ-COMP-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: T9-D15 When the user follows the reporting link from the data area top page, the data area reporting page is displayed. Form Customers.Rpt is used. The business rules for this form are the same as for the Reports page described in the previous Core Application Elements section. Customers.Rpt 28

29 REFERENCE CARDS T9a-D16 T Customer information as presented in the detail display form is formatted for printing 2-up, horizontal, on 4x5 index card stock, Avery #8387. Form CustRefCards.Rpt is used to generate the report. CustRefCards.Rpt 29

30 MAILING LABELS T9b-D17 A dialog is presented requesting whether the customer shipping address or billing address information is to be printed. Form MailLabelsRpt.Parm is used: After the user makes a selection, the current selection of records is used to print Company_Name, Contact_Name, and appropriate address fields onto Avery 5196 mailing label stock. Pressing the cancel button returns the user to the Customers.Rpt page. Form MailLabels.Rpt is used to generate the report. MailLabels.Rpt 30

31 TEST CASE 10: CUSTOMER OPERATIONS Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing Customers.Opr page and associated operations Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in PROJ-COMP-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: T10-D18 When the user follows the operations link from the data area top page, the data area operations page is displayed. Form Customers.Opr is used. The core business rules for this form are the same as for the Operations page described separately in the Core Features component. The operations page displays the pre-defined operations available for this data area as described below. Operation Selection 31

32 EXPORT MAIL MERGE DATA T10a-D19 A dialog is presented requesting whether the customer shipping address or billing address information is to be exported. MailLabelsRpt.Parm is used: After the user makes a selection, the current selection of records is used to send appropriate header and detail information in a format compatible with Microsoft Word s merge function. Fields to be exported are Company_Name, Contact_Name, and appropriate address fields. 32

33 DEMOGRAPHICS DATA AREA TEST CASES TEST CASE 11: DEMOGRAPHICS SELECTION & TOP Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing DemogTop Page Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in PROJ-COMP-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: DATA AREA SELECTION T11-D20 T T11a-D20a T11b-D20b The Demographics data area provides the ability to enter, update, and maintain information in the Demographics table. A link to the Demographics data area top page appears in the Support Data Areas section of the application top page. The system restricts user access to this Data Area according to membership in the user roles described in the Access Control Matrix in the Physical Database Description. 33

34 DATA AREA TOP T11c-D21 When the user selects the customer data area link from the Application Top page, the Demographics Data Area page is presented. This page allows the user to choose to perform a predefined search, develop an ad hoc search, or add new records, has shown below. The data area top page also provides links to separate reporting and operations pages. Form DemogTop is used. The core business rules for this form are the same as for the Data Area Top page described separately in the Core Features component. Additional business rules for this form are described below. DemogTop PRECONDITIONS None INITIALIZATION RULES T11d-D21a T A Quick Search link and description is installed in the Pre-defined search section of this form. No other predefined searches are available. INTERACTION RULES T11e-D21b T Clicking on the Quick search link initiates a Quick Search as described in the searches section below. 34

35 CONCLUSION RULES None 35

36 TEST CASE 12: DEMOGRAPHIC SEARCHES Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing DemogTop searches section and associated searches Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in PROJ-COMP-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: QUICK SEARCH T12-D22 A dialog is presented consisting of a popup list of indexed fields for the main table of the data area, along with a popup list of comparison operators, an enterable Value field, and Submit/Cancel buttons. Form Quick.Qry is used: The user is allowed to select one field, one comparison operator, and enter a value to be compared against. Clicking the Submit button executes the search as constructed by the user. The result set is presented in the summary listing. Clicking the Cancel button returns to the DemogTop page. 36

37 TEST CASE 13: DEMOGRAPHIC SUMMARY LISTING Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing Demog.L Page Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in PROJ-COMP-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: T13-D23 After completing a search or add records operation, the user is presented with a summary listing of records that match the search criteria, or the newly entered records. Form Demog.L is used. The core business rules for this form are the same as for the Summary Listing page described separately in the Core Features component. Demog.L 37

38 TEST CASE 14: DEMOGRAPHIC DETAIL DISPLAY Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing Demog.D Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in PROJ-COMP-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: T14-D24 The detail display for each data area is presented when a user clicks on a record link from a summary page, or on a Next / Previous / First / Last button on another record. Form Demog.D is used. The core business rules for this form are the same as for the Detail Display page described separately in the Core Features component, as well as the field characteristics described in the Data Dictionary section of the PDD and the range limitations and other special rules described in the Database Triggers section of this document. Specific business rules for this form are described below. Demog.D PRECONDITIONS None INITIALIZATION RULES T14a-D24a T If a new record is being added, the Demographic ID is automatically assigned by the system. 38

39 INTERACTION RULES None CONCLUSION RULES None 39

40 TEST CASE 15: DEMOGRAPHIC REPORTS Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing Demog.Rpt Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in PROJ-COMP-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: T15-D25 When the user follows the reporting link from the data area top page, the data area reporting page is displayed. Form Demog.Rpt is used. The core business rules for this form are the same as for the Reports page described separately in the Core Features component. The reports page displays the pre-defined reports available for this data area as described below. Demog.Rpt 40

41 TEST CASE 16: DEMOGRAPHIC OPERATIONS Test Class Test Item(s) Description Input Specifications Output Specifications Environmental Needs Special Procedural Requirements Intercase Dependencies Black Box Testing Demog.Opr and associated operations Validate that the page functions as specified. Manual data entry. Screen response. Client and server hardware + software connected via network, as specified in PROJ-COMP-SDD: Design Document, Design Constraints Compliance paragraphs. TEST STEPS Validate each of the following statements: T16-D26 When the user follows the operations link from the data area top page, the data area operations page is displayed. Form Demog.Ops is used. The core business rules for this form are the same as for the Operations page described separately in the Core Features component. The operations page displays the pre-defined operations available for this data area as described below. Demog.Opr EXPORT DEMOGRAPHIC DATA T16a-D27 T All fields for all Demographic records are exported as a tab-delimited text file, compatible with Microsoft Excel. 41

42 ANALYSIS LISTING The following listing is automatically maintained by the word processor for this document. It is of use only to systems analysts when verifying requirements traceability across documents. T1A-D1 T1B-D1 T1C-D1 T1D-D2 T1E-D2A T1F-D3 T2A-D1 T2B-D1 T2C-D1 T2D-D1 T2E-D1 T3A-D4 T3B-D4A T3C-D4B T3D-D4C T3E-D4D T3F-D4E T3G-D4F T3H-D4G T3I-D4H T3J-D4I T3K-D4J T3L-D4K T4-D5 T4A-D5A T4B-D5B T5-D6 T5A-D6A T5B-D6B T5C-D7 T5D-D7A 42

43 T5E-D7B T5F-D7C T5G-D7D T5H-D7E T5I-D7F T5J-D7G T5K-D7H T5L-D7I T5M-D7K T6-D8 T6A-D9 T6B-D10 T6C-D11 T6D-D12 T7-D13 T8-D14 T8A-D14A T8B-D14B T8C-D14C T8D-D14D T8E-D14E T8F-D14F T8G-D14G T8H-D14H T8I-D14I T8J-D14J T8K-D14K T8L-D14L T9-D15 T9A-D16 T9B-D17 T10-D18 T10A-D19 T11-D20 T11A-D20A T11B-D20B T11C-D21 T11D-D21A T11E-D21B T12-D22 T13-D23 T14-D24 T14A-D24A T15-D25 T16-D26 T16A-D27 43

44 44