Itil - Service Validation And Testing 401q51

ITIL – Service Validation and Testing Service Validation and Testing is "The Process responsible for Validation and Testing of a new or Changed IT Service. Service Validation and Testing ensures that the IT Service matches its Design Specification and will meet the needs of the Business According to ITIL, Service Validation and Testing is "The Process responsible for Validation and Testing of a new or Changed IT Service. Service Validation and Testing ensures that the IT Service matches its Design Specification and will meet the needs of the Business." Service Validation and Testing ensures Quality of Service (QoS). The specifications or requirements for Service qualities are defined in the Service Design phase. The deciding factor for quality Service within Service Management is testing. The main requirements for the successful testing of a Service are defined in Service Level Packages (SLPs). The frameworks drawn up in the Release, Validation and Control (RCV) phase, which guide and the implementation of quality requirements in the RCV process are  Service quality policy  Risk policy  Service Transition policy  Release policy  Change Management policy A test strategy defines the organization of tests and the allocation of resources for the tests. Tests that revel the Utility (usability) of a Service are structured tests. However, there are tests that reveal the adherence with Warranty targets and with the guarantee of the Service level. Tests on contractual and regulatory requirements ensure corporate and IT governance. Overview When you implement a Service Change, it is necessary to evaluate its effectiveness. The Change should fulfill expectations to avoid instances of mismatches between expectations and Service Delivery. To do this, you need to validate and test the Service before you implement it to ensure its fitness for use and value for money. Because every organization aims to meet customer requirements by providing quality Service, ITIL includes the Service Validation and Testing process. This process helps you fulfill customer expectations for any new or changed Service by providing assurance of quality. You must that Testing and Validation oi a key area within Service Management. In fact, lack of Testing and Validation might lead to an impression that the Service itself is inefficient. Consequently, it is important to implement best practices in this area and improve the overall Service Delivery.

Testing and Validation is a new process introduced in ITIL covered some aspects of Release testing within the Release Management process. ITIL gives more detailed guidance. A major addition is details on various testing stages during Service Transition and descriptions of their testing approaches.

5.1 Purpose, Goal and Objectives Purpose The purposes of Service Validation and Testing are:  Plan and implement a process that will provide objective evidence that the Service Change will fulfill the customers' and stakeholders' business needs and deliver the appropriate level of Service.  Provide quality assurance of the Service and its components  Identify and address all the issues, errors and Risks in Service Transition Goal The goal of Service Validation and Testing is to assure that the Service will provide value to customers and fulfill their business requirements Objectives The objectives of Service Validation and Testing are:  Give confidence that a Release will create a new or changed Service or Service offering that delivers the expected outcomes and value for the customers within the projected costs, capacity and constraints  Check that a Service is "fit for purpose" - it will deliver the required performance with the desired constraints removed  Ensure that a Service is "fit for use" - it meet certain specifications under specified and conditions of use  that the customer and stakeholder requirements for the new or changed Service are correctly defined and rectify any errors or variances early in the Service Lifecycle, because this is considerably cheaper than fixing errors in production.

5.2. Scope of the Process and Value to Business Scope of Service Validation and Testing  Deliver and maintain Services within a specified Warranty level and Service agreement  Ensure the quality and timely delivery of a Service that meets all the requirements of a successful Service Release  Understand the supplier, customer and partner requirements clearly, to validate and test the Service. Service Validation and Testing happens within a limit specified by the process and organization  Test the new or changed Service in the target Business Unit, Service Unit, deployment group or environment Usually, a Service Provider is responsible for delivering, operation and/or maintaining customer or Service Assets at specified levels of Warranty under a

Service agreement. To do this successfully, you need to coordinate with suppliers, customers and partners for validating and testing a Service. You use Service Validation and Testing throughout the Service Lifecycle to ensure Service quality, meet customer requirements and deliver the Service successfully. To do this, you nede to understand factors such as process interfaces and organizational interfaces, which will define the limits of the Service you have to test. Testing directly s the Release and Deployment process by ensuring that appropriate and necessary tests are performed at various levels in the build and deploy activities. Testing is applicable to hardware, software or knowledge-based Services developed in-house and includes the testing of new or changed Services and Service components. Value of Service Validation and Testing If the new or changed Service meets all the requirements and has had a successful Release, it has a positive effect on the business of the Service Provider as well as the customer. On the other hand, if the Service fails to deliver as expected, it might lead to loss in the business, revenue, reputation and time. When you implement Service Validation and Testing, it enables you to ensure the expected quality and assure the customer that the new or changed service will deliver the expected results. The assurance level, however, differs based on the complexity of business requirements and the environment of organizations. Service Validation and Testing Policies  Service quality policy o The organization's management defines quality. Service Strategy defines four quality parameters: level of excellence, value for money, conformance with specifications and meeting or exceeding expectations. The Service Provider has to meet one or more of these parameters to measure the quality of the Service. These parameters help evaluate how good the design of the Service is  Risk policy o Each organization, customer, business or Service Unit has a different perspective of Risk and its management. Consequently, having a Risk, policy in place ensures that the validation and testing team can control and minimize all Risk types, such as availability, security, continuity and capacity Risks  Service Transition policy o Each organization should define a policy to help the senior management manage all Changes to Services through Service Transition. The Service Provider requires this policy to align Service Transition plans with business needs using a standard framework. This policy also includes principles that will guide you to handle all







activities related to Service Changes with respect to Service Transition principles Release policy o The testing approach that a Service Provider will follow for a Service depends on the type and frequency of Release. Consequently, it is important that the organization define a Release policy to state the frequency and type of Releases, based on which it can use specific, reusable Test Models or automated testing to improve efficiency Change Management policy o The Change Management policy may allow substitution late in the Change schedule. If this is the case, more testing may be required to test the new combination that is going to be released. The additional testing defined in the testing policy will and validate the Service again to avoid any gaps with the requirements Service Transition policy o The Service Transition policy helps the senior management:  Define, document and approve a policy for Service Transition that all departments of an organization can implement  Manage all Changes to Services through Service Transition  Implement a standard framework for Service Transition, which constitutes reusable processes and systems, to improve efficiency and reduce variance in results  Adopt and introduce existing or new processes and systems in the organization that you can reuse to improve efficiency and effectiveness  Align Service Transition plans with business requirements and manage Service Changes to improve effectiveness and business value  Adopt and maintain relationships with stakeholders to understand their requirements for new or changed Services  Apply a controlled and disciplined process to manage Service Changed and Releases  Develop systems and processes for knowledge transfer, which helps you function correctly  Plan and design Release Packages to deliver Services at a low cost and effectively  Manage and apply corrections in the course of the transition  Manage all the resources across Service Transition to avoid delays  Validate the Service Change early in the Service Lifecycle to ensure that the Service Change meets all the expectations  Evaluate and assure that the new or changed Service functions and performs as expected  Plan and improve the quality of the new or changed Services during Service Transition

o 

Testing Policy The Testing policy usually reflects the requirements from Service Strategy

Example of Policy Statements  Test the library and reuse policy: because the nature of IT Service Management is repetitive, it benefits from reuse  Integrate testing into the project and Service Lifecycle  Adopt a Risk-based testing approach aimed at reducing Risk to the Service and the customer's business  Engage with customers, stakeholders, s and Service teams throughout the project and Service Lifecycle  Establish test measurement and monitoring systems to improve the efficiency and effectiveness of the Service Validation and Testing and Continual Service Improvement (CSI) processes  Automate the policy using automated testing tools and systems Test Model A Test Model includes a test plan and test scripts that define the testing approach for testing each element, Release test conditions, predicted results and test cycles. The details in the Test Model enable you to ensure that whenever you repeat tests on a Service, you do so efficiently and effectively. As a result, a Test Model should be well structured and enable you to  Trace elements to the requirements or design stage  Audit tests  Change and maintain test elements As you progress in the Service Design phase, you can use the updated Service Design and Release plan to define the specific requirements, validation, test conditions cases and mechanisms to be tested. Test model

Objective/target deliverable

Test conditions based on

Service contract test model

To validate that the customer can use the service to deliver a value proposition

Contract requirements. Fit for purpose, fit for criteria

Service requirements test model

To validate that the service provider Service requirements and can/has delivered the service required and Service Acceptance criteria expected by the customer

Service level test model

To ensure that the service provider can Service level requirements deliver the service level requirements, and SLA, OLA service level requirements can be met in the production environment, e.g. testing the response and fix time, availability, product delivery times, services,

Service test model

To ensure that the service provider is capable of delivering, operating and managing the new or changed service

Service model

using the "as-designed" service model that includes the resource model, cost model, integrated process model, capacity and performance model, etc Operations test model

To ensure that the Service Operations Service model, Service teams can operate and the new or Operations standards, changed service/service component processes and plans including the service desk, IT operations, application management, technical management. It includes local IT staff and business representatives responsible for IT service and operations. There may be different models at different release/test levels, e.g. technology infrastructure, applications

Deployment release test model

To that the deployment team, tools Release and deployment and procedures can deploy the release design and plan package into a target deployment group or environment within the estimated timeframe. To ensure that the release package contains all the service components required for deployment, e.g. by performing a configuration audit

Deployment installation test model

To test that the deployment team, tools and procedures can install the release package into a target environment within the estimated timeframe

Release and deployment design and plan

Deployment To test that a deployment has completed Tests and audits of "actual verification test model successfully and that all service assets and service assets and configurations are in place as planned and configurations" meet their quality criteria The Service V-Model This model helps you:  Meet customer requirements and ensure quality early in the Service Lifecycle  Provide a framework to organize the Configuration Item levels and their validation and testing activities across the Lifecycle stages  Map the types of tests to each development stage The Service V-Model gives one example of the way testing levels in Service Transition can be mapped to their corresponding stages of Service requirements and design In the Service V-Model  The left side of the diagram represents the Service requirements specification down to the detailed Service Design



The right side of the diagram represents the validation activities that you perform against the specifications defined on the left

Each stage on the left has a corresponding activity on the right. This means that you must start the Service Validation and acceptance test planning with the definition of Service requirements. The customer who signs-off the Service requirements will also sign-off the Service Acceptance Criteria (SAC) and test plan. Validation and Testing Perspectives Successful validation and testing focuses on the following question: Will the Service deliver as required? The answer to this question is based on the perspective of those who will do the following activities for the Service  Use  Deliver  Deploy  Manage  Operate Service Acceptance Testing This starts with ing Service requirements, which are, in turn, based on customer requirements. Customers, Service Providers and other stakeholders sign-off the Service requirements, Acceptance Criteria and Service acceptance test plan before you start building the Service. Stakeholders can be:  Business customers or customer representatives  s of the Service  Suppliers  Service Providers or Service Units It is important to consider the perspective of all the roles involved in the implementation of the Service Change. The different perspectives are:  Perspective of business s and customers  Perspective of the Service Provider  Perspective of end s within the customer's business  Perspective of Operations and Service Improvement To start with, let us discuss the importance of the perspectives of business s and customers. Perspective of Business s and Customers The business s' and customers' perspectives are important to the success of the Service because they  Allow you to have a defined way of measuring the acceptability of the Service  Plan for the resources and level of expertise required to undertake Service Acceptance Perspective of the Service Provider

from the Service Provider helps you  Be involved with the business prior to testing to avoid surprises during Service acceptance  Ensure the quality of the Service. This plays a key role in influencing Business Units about the quality, reliability and usability of the Service even before the Service goes live  Deliver and maintain robust acceptance test facilities per business requirements  Understand how the acceptance test fits into the business service or product development testing activity Perspective of End s Within the Customer's Business You must do a Acceptance Test after building the service. This ensures that the customer checks and verifies the Service before accepting it. You must test the Service in an environment that closely resembles the live operational environment. The testing helps you determine whether the Service is meeting the customer's expectations. You must define the testing details and scope in the test and UAT plans, which the stakeholders should agree to at the start of the process. The end s within the customer's business will:  Test the functional requirements of the Service to ensure that it meets their expectations  Perform tests on Service Management activities, such as the ability to use the Service Desk, respond to diagnostic scripts, Incident Management, Request Fulfilment and Change Request Management You must ensure that you set the expectations of the customers at the onset of these tests. This is to avoid any early testing dissatisfaction. You must explain to the customers that this is just a test and that it is possible the Service will not perform as expected in all aspects. Perspective of Operations and Service Improvement The operations staff must ensure that they deliver all the IT staff requirements to the customer before deployment. The from the operations staff helps you:  Set up technological facilities before delivering the new or changed service  Provide the relevant staff skills, knowledge and resources to the Service after it goes live  Arrange for ing processes and resources, such as the Service Desk and second -or third- line  Consider business and IT continuity  Provide access to documentation and the Service Knowledge Management System (SKMS) After knowing the perspectives of the various roles involved in the Service implementation, you need to apply the appropriate testing model and thoroughly test the Service by considering the various perspectives.

All the components and assets of the Service are tested separately using a specific Test Model. Also, each component must have an associated acceptance test in addition to the overall acceptance criteria of the Service. All the Service Models and associated Service deliverables are ed by their own reusable Test Model. You can use this Test Model during deployment and in future testing. These Test Models help you ensure quality at an early stage instead of waiting for at the end.

5.5 Main Activities, Methods, Techniques and Relationship with RCV Testing Process The testing process involves several activities. However, these activities are not performed in sequence. You can perform them in parallel. Important activities in the testing process are:  Validation and test management: In this, you: o Plan, control and report activities through the test stages of Service Transition o Manage issues, mitigate Risks and implement Changes identified from the testing activities. These Changes can delay the implementation and create dependencies that you must manage  Plan and design test: you plan and design in the early Service Lifecycle phase. To plan and design, you need to: o Plan resources such as hardware, networking and staff o Identify business and customer requirements, such as raw material o Plan for ing Services and their features, such as access and security o Create schedules and get approval for them o Define the timelines and place for Service Delivery o Define financial requirements  the test plan and test design: you need to the test plan and test design to ensure that: o The Test Model delivers appropriate test coverage for the risk profile of the Service o The Test Model covers the key integration aspects and interfaces o The test scripts are accurate and complete  Prepare the test environment: you must define the design plan of the initial test environment. You can prepare the test environment by using the: o Services of the build and test environment resource o Release and Deployment processes  Perform tests: in this, you need to: o Use manual or automated techniques and procedures to perform the tests

Record the results of the tests. Even if the test fails, you must document the result along with the reason for the failure of the test o Follow the test plan and scripts for testing, whenever possible o Resolve and document the Incident or issue when part of the test fails. The person who is testing that part of the Service should resolve the issue and test it again Evaluate exit criteria and report: When you evaluate the exit criteria and exit report, you need to: o Compare the predicted results to the actual results o Interpret the results in of Risk to the business, Risk to the Service Provider, or change in expected cost o Collate the test metrics and summarize the results of the tests o Evaluate the exit criteria based on the performance of the Service and client . The Service must meet the customer's technology and quality requirements o Ensure that Configuration Baselines have been recorded in the Configuration Management System (CMS) Test clean-up and closure: In this, you need to: o Clean or initialize the test environments o Identify improvements that can be input to design, build, decision parameters or future testing policies and procedures o





Validation and Test Management Includes the following activities:  Plan the test resources  Prioritize and schedule what is to be tested and when  Manage Incidents, Problems, errors, nonconformance, Risks and issues  Implement Changes to reduce errors going into production  Record Configuration Baselines  Collect, analyze, report and manage test metrics Test Metrics  Measure the test process and manage and control the testing activities  Determine the progress of testing, the earned value and the outstanding testing. The Test Manager uses this data to estimate the duration of the testing  Help the management prioritize, schedule and manage Risk  Provide information to estimate and schedule future Releases Outputs of the Perform Tests Activity  Reports with details of testing along with cross-references to the Test Model, test cycles and conditions  Data for Problems, errors, issues, nonconformance and Risks that you have to resolve  Data for resolved Problems, Known Errors and related Changes  Sign-off document Guidelines to Prepare the Test Environment

Use Service Management best practices to actively maintain and protect test environments. For significant Changes, the possibility that the test data needs to be updated should be considered.

5.6 Triggers, Inputs, Outputs and Interfaces with other processes Triggers Triggers for the testing phase are a scheduled activity on a:  Release plan  Test plan  Quality assurance plan Inputs  The Service Package o Consists of a core Service Package and reusable components, in other words, ing Services. It also defines Utilities and Warranties for the delivered Services. You can use the Service Package to map the requirements to a Service Level Package (SLP).  An SLP o Plays a very important role in test planning and design because it provides Utility and Warranty based on the customer's requirements, assets and Patterns of Business Activity (PBAs)  Service Provider interface definitions o Define the process interfaces and organizational interfaces that you can use to test the Service efficiently  The Service Design Package (SDP) o Defines customer requirements for the Service along with the Service Model and the Service Operations plan. It includes:  Operation models, resource, escalation procedures and critical situation-handling procedures  Capacity/resource model and plans, along with performance and availability aspects  Financial/economic/cost models with Total Cost of Ownership (TCO) and Total Cost of Utilization (TCU)  Service Management model, for example, an integrated process model as in ISO/IEC 20000  Design and interface specifications  Release and Deployment plans o Define the order in which you need to deploy, build and install Release Units  Acceptance Criteria o Consist of specific requirements for testing at all levels  Request for Change (RFC) o Is a request for a new Service or a Change to an existing Service Output

The output from the process is the test report that you need to forward to the Evaluation team. This report includes all information relevant to the testing phase, such as details of the testing environment and test results. Based on the output, you can evaluate the Service only after a specific duration of the Service going live. At that time, you can compare the predicted performance with the actual performance of the Service. If the Service is functioning as expected, the evaluation is successful. You then send a report to Change Management along with a suggestion to remove Early Life (ELS) from the Service and make it part of normal operations. Interface with the Service Lifecycle Service Validation and Testing s all steps of the Release and Deployment phase in Service Transition. You align the testing strategy to work with all other Lifecycle stages to improve the quality of the Service. Some of these interfaces are:  Service Design o Ensures that you can test the designs. For example, you can test hardware, software, Service elements that you reuse, third-party access rights or delivered Service elements  Continual Service Improvement (CSI) o Ensures that you work continuously to improve the Service and test plans  Service Operation o Uses maintenance tests to ensure that Services are effective. You will need to maintain these tests to handle innovation and environmental changes  Service Strategy o Ensures that you test the services within the specified cost and time, using limited resources Service Validation and Testing Interfaces with Other Processes The relationships from Service Validation and Testing with other processes within the RCV context are:  Service Package  Service Design Package  Service Level Package  Release and Deployment Plans  RFCs - Change Management  Configuration Baselines - Service asset and Configuration Management (SACM)  Updated knowledge in the SKMS  Test Incidents and Problems - Incident and Problem Management  Improvement suggestions - CSI

5.7 Test Data and Test Environments Testing Good Practices

IT Service Management tasks are repetitive and benefit from the reuse of predefined models, processes and formats. Some testing good practices are:  Tests library o A good, practical approach is to create and maintain a library of relevant tests and update it whenever you make any Changes. The test management group can take responsibility for organizing and maintaining test scripts, test cases and test data in an organization.  Automated testing tools o Another timesaving method is to use automated testing tools, such as Computer-Aided Software Testing (CAST). These tools enable you to test any type of Service effectively in complex software environments. Similar tools are available for hardware testing Test Data Test data is very important for running tests. If the test data is inaccurate, it will not give the required results, even if you maintain a well-designed test environment. The test data is also important in hardware and documentation tests. Test Environment Apart from test data, the test environment also plays a crucial role. This is because test results might be inaccurate if the testing environment is not constant. You must maintain and protect the test environment appropriately. If you are making a Change to a Service, you must also check if you need to make any Changes to the test data and environment. You must update the relevant records for the test data and test environment in the CMS. If necessitated by the Change:  Update the test data  Create a new set of data or a new test environment  Check for the redundancy of the test data or environment. This helps you test the Service within another, existing test environment and using another set of test data  Consider the fact that the test data and test environment might provide low-level testing because of the new or updated changed Service When maintaining the test data, you should:  Separate the test data from any live data to ensure that the test data is not mistaken for live data and ice versa  Follow data protection regulations. For example, when you use live data to create a test database, you should protect the data and ensure that it is not transferable  Create a back-up copy of the test data. You must restore the database for future testing. You can also do this for hardware tests  Use an established test database to ensure that you have a safe and realistic training environment for a Service

Test Report A test report includes:  The base configuration structure of the testing environment  Details of the test along with requirements and constraints  Test results  The test analysis, for example, a comparison of the actual performance with the expected performance and a report of the Risks identifies during the testing phase  The updated data and other information that is to be added to the SKMS, for example, errors and Workarounds, testing techniques and analysis methods  Test Incidents, Problems and errors records  Data or suggestions to improve the testing process or the process of documenting the outputs of Service Design  Information on customers, suppliers, partners and stakeholders

5.8 Process Measurement KPIs Let us understand how KPIs help you analyze validation and testing reports to identify trends. There are primary and secondary PKIs applicable for Service Validation and Testing  The primary KPIs include the indicators that you can use to judge the effectiveness of testing in delivering Services that affect the business of the organization  The secondary KPIs include KPIs to measure the effectiveness and efficiency of the testing process Primary KPIs  Validate the Service early to correct it in case of any discrepancies  Reduce Incidents and errors after deployment, which is a characteristic of newly transitioned service  Interact more efficiently with customers and Business Units  Reduce delays in testing to avoid affecting the business adversely  Understand the new or changed service  Allocate roles and responsibilities to customers, s and Service Providers when implementing a Service Change  Sign-off on cost, effort and or customer requirements. For example, at the time of acceptance testing In addition to the above primary KPIs, there are other primary KPIs to measure the economic effectiveness of the testing process. These KPs include:  Test planning, preparation and execution rates  Incident, Problem and Event rates  Issue and risk rate

           

Problem resolution rate Resolution effectiveness rate Stage containment - analysis by Service Lifecycle stage Repair effort percentage Problems and changes by Service asset or Configuration Item type Late Changes by Service Lifecycle stage Inspection effectiveness percentage Residual risk percentage Inspection and testing return on investment (ROI) Cost of unplanned and unbudgeted overtime to the business Cost of fixing errors in live operation compared to fixing errors early in the Lifecycle Operational cost improvements associated with reducing errors in new or Changed Services

Secondary KPIs  Control effort and cost to set up a testing environment  Minimize effort required to find defects, that is the number of defects  Reduction of repeat errors. from testing ensures that corrective action within design and transition (through CSI) prevents mistakes repetition in subsequent Releases or Services  Reduce error/defect rate in later testing stages or production  Re-use of testing data  Percentage Incidents linked to errors detected during testing and release into live  Percentage errors at each Lifecycle stage  Number and percentage of errors that could have been discovered in testing  Testing Incidents found as percentage of Incidents occurring in live operations  Percentage of faults found in earlier assessment stages, since there is always an increase in the remedial costs in later stages of transition  Number of Known Errors documented in earlier testing phases Testing is measuring the ability of a Service to perform as required in a simulated or actual environment. It focuses on measurement. You must ensure that you separate the measures related to the testing process from the errors introduced into Services and systems. The main aim of testing is to deliver Services that are beneficial and reduce changes of failure. You must be careful in identifying errors during the testing phase because rectifying errors after deployment involves more effort and cost.

5.9 Roles and Responsibilities There are various roles involved in executing Service Validation and Testing. However, you must always create separate roles for all the responsibilities to ensure efficient and independent testing and validation Some of the roles involved in the process are:



 

Service Test manager o Is responsible for handling the test and the test team(s) functions for specific Service Transition. The role reports to the Service Transition Manager. The roles of the Service Test Manager and Release and Deployment Manager should be undertaken by separate people and never combined to always ensure independent testing and test verification Test o Provides independent testing Build and test environment management o Ensures that relevant people have the required environment, test data and versioned software, when required. This role coordinates the use of testing resources to ensure they are used maximally

Other Responsibilities of the Service Test Manager  Defines the test strategy  Designs and plans testing conditions, test scripts and test data sets to ensure appropriate and adequate coverage and control  Allocates and oversees test resources, ensuring that they adhere to the test policies  Provides management reporting on test progress, test outcomes, success rates, issues and risks  Conducts tests as defined in the test plans and design  Records, analyses, diagnoses, reports and manages test events, Incidents, Problems and retest dependent on agreed criteria  Manages test environment requirements  Verifies tests conducted by Release and deployment teams  isters test assets and components Other Factors of Test  The Change Manager is responsible for ensuring that tests are developed appropriate for approved Changes and tat an agreed testing strategy and policy is applied to all Changes  Test analysts carry out the tests as set out in the testing plans and/or Service Package  The developer/supplier is responsible for establishing the root cause of test failures - the fault in the Service component that made the test fail. For complex situations, this may require collaboration between testing staff and development/build/supplier personnel. It should always be accepted as a possibility that faults can lie within the testing design as well as within design/development  Service Design will design the test, as an element of the overall Service Design. For many services, standard tests will exist, perhaps contained within the transition model chosen as already accepted as appropriate for the type of new or changed service under consideration  Customers and s perform customer and acceptance testing. Such resource should be able to cover the full range of profile and requirements, and adequately sign-off the conformance of a new or changed service. s will already have played a major role in helping to design the acceptance testing approaches during the design phase

Other Responsibilities of Build and Test Environment Management  Ensures and builds Service infrastructure and application as per design specification  Plans acquisition, builds, implements and maintains Information and Communications Technology (ICT) infrastructure  Ensures that the build delivery components are from controlled sources  Develops an integrated application software and infrastructure build  Delivers appropriate build, operations and documentation for the build an test environments prior to handover to Service Operations  Builds, delivers and maintains required testing environments