Conversion Code Testing Processes Sample Clauses

Conversion Code Testing Processes. SCENARIO PROCESS STEPS Online  Capture the screen behaviors of the current legacy application using video screen capture.  Match against test cases that exist and create ones that do not exist.  Generate HTML mockups and playable static screens with parameter-driven macros. This is important to prove that the re-platformed ATS provides the same outcomes as the legacy application.  Manually inspect and verify the first run of the re-platformed ATS against the legacy system-related artifacts (e.g. video recordings).  Record the re-platformed ATS screen flow. This artifact is helpful for re-running tests.  Work with the County and the artifacts to execute the required tests in the prescribed manner.  Complete this work in an iterative fashion so it can start as soon as data is available on the demonstration server and complete this work in smaller, more manageable increments. Interfaces, Reports and Batch Processing  Run and record legacy batch processing with sample data  Store this data in the KMD on the development server.  Identify the data used in the batch test above and migrate it to the target MS SQL Server running the development version of the modern database.  Run the same batch processing routine using the same data in the new environment.  Compare the resulting files, tables and datasets with the legacy system batch data via automation looking for: SCENARIO PROCESS STEPS  Technical properties, such as format, code page, line endings (in case of file outputs).  Data equivalence (identical results are expected in both, legacy and modernized files)  Other properties of the data such as sort order and other attributes  Complete additional testing using the Blu Age Compare tool to verify that all the files and database content at a persistency level is sound as well. For the conversion, Vendor will utilize an iterative, incremental, and low-risk conversion approach. Within each iteration Vendor will:  Evaluate the legacy proof cases and make adjustments to the converted cases if needed.  Perform a minimal data migration so functions converted can be tested.  Validate that the existing proof cases have been automated sufficiently.  Convert the source code through Blu Age.  Demonstrate the functionality at the end of each 2 month iteration so that Vendor and the County can validate that the converted functionality matches legacy functionality. Figure 3 depicts this process. This approach allows the County to tangibly see artifacts, ...
Sample 1Sample 2
AutoNDA by SimpleDocs
Conversion Code Testing Processes. SCENARIO PROCESS STEPS Online • Capture the screen behaviors of the current legacy application using video screen capture. • Match against test cases that exist and create ones that do not exist. • Generate HTML mockups and playable static screens with parameter-driven macros. This is important to prove that the re-platformed ATS provides the same outcomes as the legacy application. • Manually inspect and verify the first run of the re-platformed ATS against the legacy system- related artifacts (e.g. video recordings). • Record the re-platformed ATS screen flow. This artifact is helpful for re-running tests. • Work with the County and the artifacts to execute the required tests in the prescribed manner. • Complete this work in an iterative fashion so it can start as soon as data is available on the demonstration server and complete this work in smaller, more manageable increments. Interfaces, Reports and Batch Processing • Run and record legacy batch processing with sample data • Store this data in the KMD on the development server. • Identify the data used in the batch test above and migrate it to the target MS SQL Server running the development version of the modern database. • Run the same batch processing routine using the same data in the new environment. • Compare the resulting files, tables and datasets with the legacy system batch data via automation looking for: • Technical properties, such as format, code page, line endings (in case of file outputs).
Sample 1

Related to Conversion Code Testing Processes

  • Drug Testing Procedures a. The testing procedures and safeguards provided in this policy shall be adhered to by any laboratory personnel administering departmental drug tests.

  • Random Drug Testing All employees covered by this Agreement shall be subject to random drug testing in accordance with Appendix D.

  • Technical Specifications The Technical Specifications furnished on the CD are intended to establish the standards for quality, performance and technical requirements for all labor, workmanship, material, methods and equipment necessary to complete the Work. When specifications and drawings are provided or referenced by the County, these are to be considered part of the Scope of Work, and to be specifically documented in the Detailed Scope of Work. For convenience, the County supplied specifications, if any, and the Technical Specifications furnished on the CD.

  • Testing Procedure A. For alcohol testing, the member shall be first given a breath test, at the collection site, followed by a confirmatory urine test only where the breath test reveals an initial positive alcohol level of .04 grams per 210 l. of breath. If the initial breath test results are below this level, testing shall be discontinued; if confirmatory urine tests results are below a level equivalent to .04 grams per 210 l. of breath, the confirmatory test shall be considered negative.

  • Drug Testing (A) The state and the PBA agree to drug testing of employees in accordance with section 112.0455, F.S., the Drug-Free Workplace Act.

  • Procedures for Providing NP Through Full NXX Code Migration Where a Party has activated an entire NXX for a single Customer, or activated at least eighty percent (80%) of an NXX for a single Customer, with the remaining numbers in that NXX either reserved for future use by that Customer or otherwise unused, if such Customer chooses to receive Telephone Exchange Service from the other Party, the first Party shall cooperate with the second Party to have the entire NXX reassigned in the LERG (and associated industry databases, routing tables, etc.) to an End Office operated by the second Party. Such transfer will be accomplished with appropriate coordination between the Parties and subject to appropriate industry lead times for movements of NXXs from one switch to another. Neither Party shall charge the other in connection with this coordinated transfer.

  • Escrow Format Specification 3.1. Deposit’s Format. Registry objects, such as domains, contacts, name servers, registrars, etc. will be compiled into a file constructed as described in draft-xxxxx-xxxxxxx-registry-data-escrow, see Part A, Section 9, reference 1 of this Specification and draft-xxxxx-xxxxxxx-dnrd-objects-mapping, see Part A, Section 9, reference 2 of this Specification (collectively, the “DNDE Specification”). The DNDE Specification describes some elements as optional; Registry Operator will include those elements in the Deposits if they are available. If not already an RFC, Registry Operator will use the most recent draft version of the DNDE Specification available at the Effective Date. Registry Operator may at its election use newer versions of the DNDE Specification after the Effective Date. Once the DNDE Specification is published as an RFC, Registry Operator will implement that version of the DNDE Specification, no later than one hundred eighty (180) calendar days after. UTF-8 character encoding will be used.

  • Testing Procedures Testing will be conducted by an outside certified Agency in such a way to ensure maximum accuracy and reliability by using the techniques, chain of custody procedures, equipment and laboratory facilities which have been approved by the U.S. Department of Health and Human Services. All employees notified of a positive controlled substance or alcohol test result may request an independent test of their split sample at the employee’s expense. If the test result is negative the Employer will reimburse the employee for the cost of the split sample test.

  • Technical Specification As enumerated in Special Conditions of Contract/Scope of Work/attached Drawing/ Details/Schedule of Rates.

  • EODUF Packing Specifications 7.3.1 The data will be packed using ATIS EMI records. A pack will contain a minimum of one (1) message record or a maximum of ninety-nine thousand nine hundred and ninety-nine (99,999) message records plus a pack header record and a pack trailer record. One transmission can contain a maximum of ninety-nine (99) packs and a minimum of one (1) pack.

Time is Money Join Law Insider Premium to draft better contracts faster.