FUNCTIONALITY TESTING Clause Samples

The FUNCTIONALITY TESTING clause establishes the requirement for verifying that a product, system, or service performs according to specified functional criteria before acceptance or deployment. Typically, this involves conducting tests or demonstrations to confirm that all agreed-upon features and operations work as intended, often as a prerequisite for final delivery or payment. By mandating such testing, the clause ensures that the delivered solution meets contractual expectations and helps prevent disputes over performance or incomplete deliverables.
FUNCTIONALITY TESTING. Functionality Testing shall test whether the Release or Function being tested operates in accordance with the Functionality in the test environment without regard to Performance Metrics.
View Source
FUNCTIONALITY TESTING. 12.3.1. Upon delivery of any Tested Deliverables, SARS shall conduct Acceptance Testing thereof and record in writing the outcome of the Acceptance Testing, including any failures or exceptions noted during the Acceptance Testing. 12.3.2. During Acceptance Testing, the Service Provider shall assist SARS, to the extent necessary and reasonable, in conducting the Acceptance Testing and respond to any queries relating to the operation and/or functionality of any Tested Deliverables within a reasonable time. The Service Provider shall further assist SARS with the evaluation of such Tested Deliverables. 12.3.3. Should SARS not accept the Tested Deliverable and/or its related documentation, SARS shall provide the Service Provider with written notice of its non-acceptance of such Tested Deliverable. The Acceptance Testing will be repeated in respect of such failures or any element which was not approved by SARS in order to correct any Deficiencies in such Tested Deliverable, until SARS is satisfied with the outcome of the Acceptance Testing. The Service Provider shall correct any Deficiencies in such Tested Deliverable and its related documentation within 24 (twenty-four) hours of receiving SARS’s notice to ensure that they are free from Deficiencies and conform to SARS’s business and security requirements, where after such Tested Deliverable will be resubmitted to Acceptance Testing in accordance with the provisions of Clause 11.3. 12.3.4. If the Service Provider is unable to correct such Deficiencies within a period of 14 (fourteen) days, SARS shall, without limiting any of its other rights contained in this Agreement, be entitled to a refund of the fees paid for such Tested Deliverable and its related Documentation and shall return the Deliverable and its related Documentation to the Service Provider. Such refund shall be made within 14 (fourteen) days of receiving SARS’s notice. 12.3.5. The Service Provider will ensure that the Tested Deliverable procured in terms of this Agreement are compatible with the information technology and telecommunications standards and architectures of SARS. This information is available to the Service Provider upon prior written request. 12.3.6. Once SARS is satisfied with the outcome of Acceptance Testing, SARS will furnish the Service Provider with a formal acceptance of the functionality of the Tested Deliverable.
View Source
FUNCTIONALITY TESTING. (a) An X.25 DTE attached via Tail Circuit to a Node is able to establish link level communications with the Node local to the Location. (b) An X.25 DTE attached via Tail Circuit to a Note is able to place an X.25 call to pre-designated address, transfer data and then clear the virtual connection than has been established. ALTERNATIVE TESTING ------------------- Where local PTT operating conditions are such that the above commissioning tests are not appropriate, Scitor ITS shall be entitled to carry out alternative commissioning tests as agreed by Customer. In this event Scitor shall provide to the Customer a description of these alternative commissioning tests. ATTACHMENT 4 - NETWORK PATH AVAILABILITY / NETWORK TRANSIT TIME WARRANTIES The following Service warranties shall apply: NTT NPA From To (milliseconds) (%) ---- -- ------------ --- San Francisco Mexico City 375 98.81 Service warranties for additional Locations shall be as specified in supplements. AMENDMENT NO. 1 TO THE MANAGED DATA NETWORK SERVICES AGREEMENT NO. MDNS/US/NC/95-99 DATED APRIL 28, 1995 BETWEEN SCITOR INTERNATIONAL TELECOMMUNICATIONS SERVICES INC. (SCITOR ITS) AND NETSTAR INTERNATIONAL TELECOMMUNICATIONS, INC. ( CUSTOMER ) This Amendment is made by and between Scitor ITS having its principal place of business located at ▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇, ▇▇▇▇▇ ▇▇▇▇, ▇▇▇▇▇▇▇, ▇▇▇▇▇▇▇ ▇▇▇▇▇, Ratsten, Inc., d/b/a Netstar International Telecommunications, having its principal place of doing business located at ▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇ ▇▇▇▇, ▇▇▇▇▇▇▇▇▇▇, ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇ ("Netstar") and GFP Group, Inc., having its principal place of business at ▇▇▇▇ ▇▇▇▇▇▇▇▇ ▇▇▇. E., Suite ▇▇▇, ▇▇▇▇▇▇▇, ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇ ("GFP Group"). In consideration of the convenants, premises and agreements set forth below, and in consideration of those set forth in the Agreement which this Amendment supplements, the parties do hereby agree as follows:
View Source
FUNCTIONALITY TESTING. (a) An X.25 DTE attached via Tail Circuit to a Node is able to establish link level communications with the Node local to the Location. (b) An X.25 DTE attached via Tail Circuit to a Note is able to place an X.25 call to pre-designated address, transfer data and then clear the virtual connection than has been established.
View Source
FUNCTIONALITY TESTING. (a) An X.25 DTE attached via Tail Circuit to a Node is able to establish link level communications with the Node local to the Location. (b) An X.25 DTE attached via Tail Circuit to a Note is able to place an X.25 call to pre-designated address, transfer data and then clear the virtual connection than has been established. ALTERNATIVE TESTING ------------------- Where local PTT operating conditions are such that the above commissioning tests are not appropriate, Scitor ITS shall be entitled to carry out alternative commissioning tests as agreed by Customer. In this event Scitor shall provide to the Customer a description of these alternative commissioning tests. ATTACHMENT 4 - NETWORK PATH AVAILABILITY / NETWORK TRANSIT TIME WARRANTIES The following Service warranties shall apply: NTT NPA From To (milliseconds) (%) ---- -- ------------ --- San Francisco Mexico City 375 98.81 Service warranties for additional Locations shall be as specified in supplements.
View Source
FUNCTIONALITY TESTING. OM will demonstrate satisfactory functionality testing of the Demo Unit to the satisfaction of PHYTOCHEM.
View Source
FUNCTIONALITY TESTING. In the functionality testing we have to do the checks that are related to links in other web pages (both internal and external), the checks that are related to database connections (especially when the databases are remote), the checks to the forms used in the web pages for submitting or getting information from user and their validation, and finally to do the cookie testing.
View Source

Related to FUNCTIONALITY TESTING

  • Stability Testing Patheon will conduct stability testing on the Products in accordance with the protocols set out in the Specifications for the separate fees and during the time periods set out in Schedule C. Patheon will not make any changes to these testing protocols without prior written approval from Client. If a confirmed stability test failure occurs, Patheon will notify Client within [***], after which Patheon and Client will jointly determine the proceedings and methods to be undertaken to investigate the cause of the failure, including which party will bear the cost of the investigation. Patheon will not be liable for these costs unless it has failed to perform the Manufacturing Services in accordance with the Specifications and cGMPs. Patheon will give Client all stability test data and results at Client’s request.

  • Functionality Customer is entitled to additional functionality previously purchased or bundled with the software if available in the version or update released on or after the start date of the Agreement. Customer acknowledges that certain functionality in current and previous software versions may not be available in future upgrades. Added functionality may require additional paid services (clinical and technical) to configure and support.

  • ODUF Testing 6.6.1 Upon request from TWTC, AT&T shall send ODUF test files to TWTC. The Parties agree to review and discuss the ODUF file content and/or format. For testing of usage results, AT&T shall request that TWTC set up a production (live) file. The live test may consist of TWTC’s employees making test calls for the types of services TWTC requests on ODUF. These test calls are logged by TWTC, and the logs are provided to AT&T. These logs will be used to verify the files. Testing will be completed within thirty (30) days from the date on which the initial test file was sent.

  • Performance Testing (a) All performance tests of the Project, including any Initial Performance Test required in Section 2 of Appendix VIII, will be performed in accordance with the test procedures set forth in Appendix VIII (“Performance Test”), including additional procedures and protocols related to Performance Testing as mutually agreed between Buyer and Seller (“Test Procedures”). Seller shall bear all costs and receive all revenues, if applicable, associated with all Performance Tests. (b) After the Initial Delivery Date and during the Delivery Term, Buyer will have the right to conduct a Performance Test (“Buyer Performance Test”) no more than once a calendar year to demonstrate whether the Project is capable of delivering the Distribution Services at the Contract Capacity. Within 30 calendar days following a Buyer Performance Test, Seller will have the right to retest the Project with a Performance Test (“Seller Retest”). For the avoidance of doubt, the results of any Seller Retest will supersede the results of the preceding Buyer Performance Test. (i) If a Buyer Performance Test or, if a corresponding Seller Retest has occurred, a Seller Retest demonstrates the Project is capable of delivering Distribution Services at or above ninety-nine percent (99%) of the Initial Contract Capacity, the Contract Capacity will remain the Initial Contract Capacity; (ii) If a Buyer Performance Test or, if a corresponding Seller Retest has occurred, a Seller Retest demonstrates the Project is capable of delivering Distribution Services at more than or equal to eighty-five (85%) of the Initial Contract Capacity, but less than ninety-nine percent (99%) of the Initial Contract Capacity (“Testing Band”), the Contract Capacity will be automatically adjusted (upwards or downwards) to the capacity commensurate with the amount of Distribution Services the Project delivered during the Performance Test within the Testing Band. (iii) If a Buyer Performance Test or, if a corresponding Seller Retest has occurred, a Seller Retest demonstrates the Project is not capable of delivering Distribution Services of at least eighty-five percent (85%) of the Initial Contract Capacity, an Event of Default shall occur in accordance with Section 7.1(a)(viii).

  • Service Specification The Parties have agreed upon the scope and specification of the Services provided under this Service Agreement in the Service Specification.