Software Developer Testing Automation. Felecia Coley Manager, E-File & Development Unit North Carolina Department of Revenue

Transcription

1 Software Developer Testing Automation By Felecia Coley Manager, E-File & Development Unit North Carolina Department of Revenue

2 Why NCDOR Automated SWD Process Overview of the Automated Process Data Entry System Setup Database Structure Processing Submissions Conclusion 2

3 Mimic Production Provide the same functionality as production to help streamline the process Ensure production process is performing as expected. Improve Testing Process More efficient for both NCDOR & Software Developers Lessen the review time & provide more timely compare results. 3

4 Our IT programmer created an Excel spreadsheet enhanced with Visual Basic Code to handle special processing. 4

5 All test cases are entered into the spreadsheet for each software developer product. The data entered for each test case represent the values that NC expects to receive from developers. This also includes separate test cases for every variation due to software limitations. 5

6 6

7 Data Entry Cont d. The data then goes through special processing using Microsoft XML libraries. o The data is validated against the schemas using the Validate XML function. o Any issues are logged in a separate worksheet and will have to be resolved before proceeding. 7

8 Data Entry Cont d. A processing log will display each test case and alert the DOR employee if the test case passed schema validation or not. 8

9 Data Entry Cont d. If errors were identified, the following screen would be displayed: 9

10 Data Entry Cont d. The log will display schema validation error constraint(s) and the element(s) in which the error occurred. 10

11 Once the test cases are validated successfully, the spreadsheet is then sent to IT for further processing. IT will execute Visual Basic code against the spreadsheet to generate SQL database statements. Example of sample SQL database statements: INSERT INTO mef.sd_set (set_id) VALUES (513); INSERT INTO mef.sd_case (set_id, case_id, identity number) VALUES (513, 1, ' '); INSERT INTO mef.sd_item (set_id, case_id, item_id, xpath, description, line_num, expected_values, always_show, test_none_info_only, test_as_numeric, test_ignore_case) VALUES (518, 13, 70, '//ReturnHeaderState/Filer/Primary/TaxpayerName/FirstName', 'Primary First Name D-400', '', 'Michael', 0, 0, 0, 1); 11

12 The SQL statements are executed in the database. The template data is then stored in the appropriate database tables. o SD_SET Group of Test Cases o SD_CASE Test Case o SD_ITEM Line Items 12

13 The database for Software Developer checking is made up of 4 core tables. The first two tables store the template data NCDOR expect to receive. SD_CASE SD_ITEM The other two tables are used for storing the actual data received from the software developers along with comparison information. SD_CASE_ACTUAL SD_ITEM_ACTUAL 13

14 Once the submissions are received from the software developers, the submissions are loaded into our MeF system. Schema validation will occur Business Rule validation will occur If the submission fails validation, it will be rejected and will not process any further. If the submission passes validation, the system will process the submission through an additional phase. 14

15 Processing Submissions Cont d. A Software Developer Test plug-in is used to look up each incoming submission in the template database tables SD_CASE & SD_ITEM based on the primary SSN. If a match is found, each line will be individually compared to see if the expected value from the template file matches the actual value that was given by the software developer. The submission values are then stored into the Actual tables database along with the comparison results. Once the comparison is complete, the system will send an of the comparison results to the Software Developer and the E-File Unit. 15

16 The contains a list of test submissions received, along with the individual line items where differences were identified. The will only include submissions that passed schema & business rule validation. 16

17 2 nd part of 17

18 An is sent to the NCDOR E-file Unit alerting the team that a software product successfully transmitted all required submissions with no business rule or schema validation errors. 18

19 If no discrepancies are found in the automated comparison, then the developer is ready for the final step in the approval process. If discrepancies are found, the developer will have to re-submit until no discrepancies are identified. 19

20 Requires manual data entry upfront for setup. Automated comparison is beneficial to both NCDOR & the Software Developers in the end! 20

21 Felecia Coley (919) & Gregory Torrance 21