Common use of TEST STRATEGY Clause in Contracts

TEST STRATEGY. 2.1 The Prime DSP shall develop and maintain the Test Strategy that shall describe, at a high-level, the Testing strategy and arrangements applicable to each and every testing activity to be conducted by the Prime DSP and each testing activity to be conducted by each Prime CSP in connection with their respective DCC Service Provider Contract (including in connection with Enduring Testing). 2.2 Not used. 2.3 The Contractor shall provide copies of the Test Strategy to the DCC promptly on request from time to time. 2.4 The Test Strategy developed by the Prime DSP is expected to include: (a) an overview of each Test Phase and Test Stage; (b) an overview of how Testing will be conducted; (c) the Testing procedure including details, amongst other things, of the scope of each Test Phase in accordance with the Test Requirements; (d) the process to be used to capture and record Test results and the categorisation of Test Incidents; (e) the method for mapping the expected Test results to the Test Success Criteria; (f) the procedure to be followed should the Test Success Criteria not be met or Test results fail to be as expected or any Stage Exit Criteria not be met, including any rectification procedure; (g) the process for the production and maintenance of Test Reports and reporting, including (if applicable) templates for the Test Reports and the Contractor’s Test Incident Management Log (or where appropriate the Prime DSP's Test Incident Management Log), and a sample plan to resolve Test Incidents; (h) the names and contact details of the DCC’s representatives (if applicable), relevant Other Service Providers' representatives and the Contractor’s Test representatives; (i) a high level identification of the resources required for Testing, including facilities, infrastructure, Test Stubs, Smart Metering Devices and other equipment, personnel and DCC and/or third party support for the conduct of the Tests; (j) for the User Integration Test Phase and Enduring Testing a high level identification of the Prime DSP and Prime CSP resources required for DCC and DCC Service Users to plan and execute their testing and to support the analysis and resolution of Test Incidents; (k) for all Test Phases, the extent of functional and non-functional testing; (l) all high-level dependencies (including any DCC Responsibilities) for the applicable Phase; (m) the technical environments required to support the Tests; and (n) the sourcing of Test Data (including confirmation of agreement from the sourcing party where this is not the Prime DSP).

TEST STRATEGY. 2.1 3.1 The Prime DSP Service Provider shall develop and maintain ensure that the Test Strategy that shall describe, includes at a high-level, least the Testing strategy and arrangements applicable to each and every testing activity to be conducted by the Prime DSP and each testing activity to be conducted by each Prime CSP in connection with their respective DCC Service Provider Contract (including in connection with Enduring Testing). 2.2 Not used. 2.3 The Contractor shall provide copies of the Test Strategy to the DCC promptly on request from time to time. 2.4 The Test Strategy developed by the Prime DSP is expected to includefollowing: (aA) an overview overall plan for the Testing of each Test Phase the Enforcement System, the CSP Interface, and Test Stagethe Services which shall comply with paragraph 5 of this schedule; (bB) an overview a brief description of how the approach to Testing will be conductedduring the Implementation Phase and after the Operational Commencement Date, including the rationale for such approach; (c) the Testing procedure including details, amongst other things, of the scope of each Test Phase in accordance with the Test Requirements; (d) the process to be used to capture and record Test results and the categorisation of Test Incidents; (e) the method for mapping the expected Test results to the Test Success Criteria; (f) the procedure to be followed should the Test Success Criteria not be met or Test results fail to be as expected or any Stage Exit Criteria not be met, including any rectification procedure; (g) the process for the production and maintenance of Test Reports and reporting, including (if applicable) templates for the Test Reports and the Contractor’s Test Incident Management Log (or where appropriate the Prime DSP's Test Incident Management Log), and a sample plan to resolve Test Incidents; (hC) the names and contact details of the DCC’s Service Provider's representatives (if applicable), relevant Other Service Providers' representatives and for the Contractor’s Test representativespurposes of the Testing; (iD) a high level identification the requirements and objectives of the resources required for Testing; (E) any dependencies affecting the Testing, including facilities, infrastructure, Test Stubs, Smart Metering Devices and other equipment, personnel and DCC and/or reliance on third party support for the conduct of the Testsparties; (jF) for the User Integration Test Phase and Enduring Testing a high level identification scope of the Prime DSP and Prime CSP resources required for DCC and DCC Service Users to plan and execute their testing and to support the analysis and resolution of Test IncidentsTesting; (kG) for all Test Phases, the extent of functional and non-functional testingany assumptions made that may impact upon Testing; (lH) all high-level dependencies (including any DCC Responsibilities) for the applicable Phaseperceived risks to Testing or risks, Service Issues or other issues as a result of Testing together with their impact and methods of mitigation; (mI) descriptions of the stages of Testing including without limitation the processes for establishing and implementing the relevant Test Specification against which the Testing will be conducted and assessed; (J) descriptions of the anticipated processes relating to Testing for achieving a Notice of Authority to Proceed in respect of each relevant Milestone including the performance of the Service Provider’s obligations in respect of Test Witnessing, Test Reports, Incident management and the business process scenarios to be used in determining whether the Test Criteria have been met; (K) the technical environments required entry and exit criteria applicable to support the TestsTesting; Schedule 4 – Testing Regime (L) the roles and responsibilities of all those involved with the Testing programme, including the Service Provider’s Personnel or personnel of TfL and/or third parties where applicable; (M) an outline of the resource requirements, including Personnel, Personnel training, test environments, and Testing tools; and how they will be used during Testing; (N) the location of the Testing; (O) the sources and mechanisms for creation of Test Data for use during Testing; (P) a description of the steps that will be taken to secure the Test Data, to process it in compliance with data protection laws, and to delete it securely; (Q) the quality management tools and processes to be used in Testing including: (1) any standards to be applied to Testing; (2) Incident and problem management processes; (3) Test results capture, logging, and tracking; and (n4) the sourcing of Test Data (including confirmation of agreement from the sourcing party where this is not the Prime DSP)progress and completion reporting.

TEST STRATEGY. 2.1 The Prime DSP Supplier shall develop and maintain the final Test Strategy that shall describe, at a high-level, as soon as practicable after the Testing strategy and arrangements applicable to each and every testing activity to be conducted by Lease Agreement Commencement Date but in any case no later than twenty (20) Working Days (or such other period as the Prime DSP and each testing activity to be conducted by each Prime CSP in connection with their respective DCC Service Provider Contract (including in connection with Enduring Testing). 2.2 Not used. 2.3 Parties may agree) after the Lease Agreement Commencement Date. The Contractor shall provide copies of the final Test Strategy to the DCC promptly on request from time to time. 2.4 The Test Strategy developed by the Prime DSP is expected to shall include: (a) an overview of each Test Phase and Test Stage; (b) : an overview of how Testing will be conducted; (c) conducted in relation to the Testing procedure including details, amongst other things, of the scope of each Test Phase in accordance with the Test Requirements; (d) Implementation Plan; the process to be used to capture and record Test results and the categorisation of Test Incidents; (e) the method for mapping the expected Test results to the Test Success Criteria; (f) Issues; the procedure to be followed should a Deliverable fail a Test, fail to satisfy the Test Success Criteria not be met or where the Testing of a Deliverable produces unexpected results, including a procedure for the resolution of Test results fail Issues; the procedure to be as expected or any Stage Exit Criteria not be met, including any rectification procedure; (g) followed to sign off each Test; the process for the production and maintenance of Test Reports and reportingReports, including (if applicable) templates for the Test Reports and the Contractor’s Test Incident Management Log (or where appropriate the Prime DSP's Test Incident Issue Management Log), and a sample plan to resolve for the resolution of Test Incidents; (h) Issues the names and contact details of the DCC’s representatives (if applicable), relevant Other Service Providers' representatives Customer's and the Contractor’s Supplier's Test representatives; (i) ; a high level identification of the resources required for Testing, including facilities, infrastructure, Test Stubs, Smart Metering Devices and other equipment, personnel and DCC reports relating to such personnel, and Customer and/or third party support for involvement in the conduct of the Tests; (j) for the User Integration Test Phase and Enduring Testing a high level identification of the Prime DSP and Prime CSP resources required for DCC and DCC Service Users to plan and execute their testing and to support the analysis and resolution of Test Incidents; (k) for all Test Phases, the extent of functional and non-functional testing; (l) all high-level dependencies (including any DCC Responsibilities) for the applicable Phase; (m) ; the technical environments required to support the Tests; and the procedure for managing the configuration of the Test environments. The Supplier shall develop Test Plans and submit these for Approval as soon as practicable but in any case no later than twenty (20) Working Days (or such other period as the Parties may agree in the Test Strategy or otherwise) prior to the start date for the relevant Testing as specified in the Implementation Plan. Each Test Plan shall include as a minimum: the relevant Test definition and the purpose of the Test, the Milestone to which it relates, the requirements being Tested and (n) , for each Test, the sourcing specific Test Success Criteria to be satisfied; a detailed procedure for the Tests to be carried out, including: the relevant Test Issue Thresholds; the timetable for the Tests including start and end dates; the Testing mechanism; dates and methods by which the Customer can inspect Test results or witness the Tests in order to establish that the Test Success Criteria have been met; the mechanism for ensuring the quality, completeness and relevance of the Tests; the format and an example of Test Data (including confirmation progress reports and the process with which the Customer accesses daily Test schedules; the process which the Customer will use to review Test Issues and the Supplier’s progress in resolving these on a timely basis; and the re-Test procedure, the timetable and the resources which would be required for re-Testing; and the process for escalating Test Issues from a re-test situation to the taking of agreement from specific remedial action to resolve the sourcing party where this is Test Issue. The Customer shall not unreasonably withhold or delay its approval of the Prime DSP)Test Plan provided that the Supplier shall implement any reasonable requirements of the Customer in the Test Plan.

TEST STRATEGY. 2.1 The Prime DSP shall develop and maintain the Test Strategy that shall describe, at a high-level, the Testing strategy and arrangements applicable to each and every testing activity to be conducted by the Prime DSP and each testing activity to be conducted by each Prime CSP in connection with their respective DCC Service Provider Contract (including in connection with Enduring Testing). The Contractor shall ensure the Test Strategy relates to all Test Activities in the applicable Test Phases and complies with all Test Requirements and DCC Requirements. The Contractor shall ensure the Test Strategy contains a V-model diagram that details the relationship of the design baseline (including Contractor Solution Design Documents and Service Management Framework documents (and equivalents of any such documents prepared by each Prime CSP) and relevant Communications Hub design documents) to the Test Stages. 2.2 Not usedThe Contractor shall review and update the Test Strategy so as to ensure that it is kept fully up-to-date and accurately reflects the status of Testing. 2.3 The Contractor shall provide copies of the Test Strategy to the DCC promptly on request from time to time. 2.4 The Test Strategy developed by the Prime DSP is expected to shall include: (a) an overview of each Test Phase and Test Stage; (b) an overview of how Testing will be conducted; (c) the Testing procedure including details, amongst other things, of the scope of each Test Phase in accordance with the Test Requirements; (d) the process to be used to capture and record Test results and the categorisation of Test Incidents; (e) the method for mapping the expected Test results to the Test Success Criteria; (f) the procedure to be followed should the Test Success Criteria not be met or Test results fail to be as expected or any Stage Exit Criteria not be met, including any rectification procedure; (g) the process for the production and maintenance of Test Reports and reporting, including (if applicable) templates for the Test Reports and the Contractor’s Test Incident Management Log (or where appropriate the Prime DSP's Test Incident Management Log), and a sample plan to resolve Test Incidents; (h) the names and contact details of the DCC’s representatives (if applicable), relevant Other Service Providers' representatives and the Contractor’s Test representatives; (i) a high level identification of the resources required for Testing, including facilities, infrastructure, Test Stubs, Smart Metering Devices and other equipment, personnel and DCC and/or third party support for the conduct of the Tests; (j) for the User Integration Test Phase and Enduring Testing a high level identification of the Prime DSP and Prime CSP resources required for DCC and DCC Service Users to plan and execute their testing and to support the analysis and resolution of Test Incidents; (k) for all Test Phases, the extent of functional and non-functional testing; (l) all high-level dependencies (including any DCC Responsibilities) for the applicable Phase; (m) the technical environments required to support the Tests; and (n) the sourcing of Test Data (including confirmation of agreement from the sourcing party where this is not the Prime DSP).

TEST STRATEGY. 2.1 3.1 The Prime DSP shall develop Service Provider shall, in accordance with Schedule 3 (Milestones and maintain Deliverables), prepare and submit to TTL a Test Strategy. As a minimum, the Test Strategy that shall describe, at a high-level, the Testing strategy and arrangements applicable to each and every testing activity to be conducted by the Prime DSP and each testing activity to be conducted by each Prime CSP in connection with their respective DCC Service Provider Contract (including in connection with Enduring Testing). 2.2 Not used. 2.3 The Contractor shall provide copies of the Test Strategy to the DCC promptly on request from time to time. 2.4 The Test Strategy developed by the Prime DSP is expected to include: (aA) an overview a high level plan for the Testing of each Test Phase the LCHS Assets and Test StageService Systems, including the scheduling of all Tests to be completed during the Implementation Phase; (bB) an overview a description and rationale of how the approach to Testing will be conductedduring the: (1) Implementation Phase; and (2) Operational Phase; (c) the Testing procedure including details, amongst other things, of the scope of each Test Phase in accordance with the Test Requirements; (d) the process to be used to capture and record Test results and the categorisation of Test Incidents; (e) the method for mapping the expected Test results to the Test Success Criteria; (f) the procedure to be followed should the Test Success Criteria not be met or Test results fail to be as expected or any Stage Exit Criteria not be met, including any rectification procedure; (g) the process for the production and maintenance of Test Reports and reporting, including (if applicable) templates for the Test Reports and the Contractor’s Test Incident Management Log (or where appropriate the Prime DSP's Test Incident Management Log), and a sample plan to resolve Test Incidents; (hC) the names and contact details of TTL's and the DCC’s representatives Service Provider's Representatives responsible for Testing; (if applicable)D) the requirements and objectives of the Testing; (E) any dependencies affecting the Testing, relevant including reliance on Interested Parties, Other Service Providers' representatives , the Insurance Provider and the Contractor’s Test representativesThird Parties; (iF) a high level identification the scope of the resources required for Testing; (G) any assumptions made by the Service Provider that may impact upon Testing; (H) the perceived risks to Testing, Service Issues or other risks and issues as a result of Testing together with their impact and methods of mitigation; (I) descriptions of the stages of Testing, including facilitiesthe processes for establishing and implementing the relevant Test Specification against which the Testing will be conducted and assessed; (J) descriptions of the anticipated processes relating to Testing for achieving a Milestone Notice, infrastructureincluding: (1) the performance of the Service Provider‟s obligations in respect of: (a) Test Witnessing; (b) Test Reports; and (c) Incident management; and (2) the business process scenarios to be used in determining whether the Test Criteria have been met; (K) the entry and exit criteria applicable to each of the Test Stages; (L) the roles and responsibilities of all those involved with the Testing programme, including TTL Personnel, Service Provider Personnel and/or personnel of Interested Parties, Other Service Providers, the Insurance Provider and Third Parties where applicable; (M) an outline of the resource requirements, including TTL Personnel, Service Provider Personnel and/or personnel of Interested Parties, Other Service Providers, the Insurance Provider and Third Parties, training of such personnel, Test StubsEnvironments, Smart Metering Devices and other equipment, personnel Testing tools and DCC and/or third party support for how such resources will be used during each Test Stage; (N) the conduct location of the Testing at each Test Stage; (O) the sources and mechanisms for creation of Test Data for use at each Test Stage; (P) a description of the steps that will be taken to: (1) secure the Test Data; (2) process Test Data in compliance with Data Protection Legislation; and (3) to delete Test Data securely; (Q) a proposed process for acceptance of: (1) relevant LCHS Assets; and (2) new versions and/or releases of Service Systems for production use, during the Operational Phase; (R) the quality management tools and processes to be used in Testing, including: (1) the standards to be applied to Testing; (2) requirement traceability mechanisms, based on the “Standard Glossary of terms used in Software Testing”, V1.3 produced by the International Software Testing Quality Board (ISTQB): Requirements Traceability Mechanism that provides the ability to identify requirements with related items in Documentation and Software, in particular, identifying requirements with associated Tests; (j3) for the User Integration Test Phase Incident and Enduring Testing a high level identification of the Prime DSP and Prime CSP resources required for DCC and DCC Service Users to plan and execute their testing and to support the analysis and resolution of Test IncidentsProblem management processes; (k4) for all Test Phases, the extent of functional and non-functional testingconfiguration management; (l5) all high-level dependencies (including any DCC Responsibilities) for the applicable Phaserelease management; (m6) the technical environments required to support the Testscapture, logging, and tracking of Test results; and (n7) Test progress and completion reporting; and (S) each of the sourcing foregoing in respect of the: (1) Business Continuity Test Data Schedule and Testing of the Business Continuity Plan; and (including confirmation of agreement from the sourcing party where this is not the Prime DSP)2) Business Continuity Infrastructure and Business Continuity Services.