Neven Zitek In some of our previous articles, we’ve already been discussing Release and Deployment Management, but in this week’s blog post I’d like to expand the topic a bit and share some information specifically regarding testing during Service Transition.
Before we continue, I suggest that you read the following articles on Release and Deployment Management principles, if you haven’t already: ITIL Release and Deployment Management Part I – General principles and service testing, and ITIL Release and Deployment Management Part 2 – deployment methods and early life support.
V-model
Figure 1 – V-model of service lifecycle configuration points
When we want to discuss service testing, we first have to look at the complete service lifecycle in order to define points in which the services, or service components, have their baseline values defined. Identification of such points is very important for Configuration Management, which will use these baseline values as reference points upon which all further activities will be based.
According to ITIL, we can use the “V-model” (as shown in Figure 1) to identify different configuration levels that have to be built and tested, following the waterfall principle; at each stage on the left-hand side, there is direct involvement by the equivalent party on the right-hand side. The left-hand side represents the specification of the service requirements down to the detailed service design. The right-hand side focuses on the validation and test activities that are performed against the specifications defined on the left-hand side.
Level 1 (Business needs) – Requirements in the form of a structured definition, i.e., Contract. Deliverable in the form of a Contract based on the Service Portfolio and service options —> Validation and Testing has to determine whether a service can enable users to use the service in a manner that supports their business needs (i.e., Warranty and Utility).
Level 2 (Service requirements) – Requirements in the form of service requirement specification and SAC (Service Acceptance Criteria), which can be traced back to contract requirements. Deliverable in the form of service capability and resources to deliver against the SLA and service requirements —> Validation and Testing has to check whether the service acceptance criteria are met, and whether service performance is aligned with the SLA, which includes the SLA in pilots and early life support.
Level 3 (Service solution) – Requirements in the form of an SDP (Service Design Package), which includes service model, environments, capacity and resource plan, etc. Deliverable in the form of solution / system required to deliver the service capability, including the service management and service operation capabilities —> Validation and Testing has to perform the service operational readiness test, which evaluates the integration of service capability and resources. It verifies that the organization and people are prepared to deploy and operate the new or changes service in the live environment. This may include scenario-based testing (simulation and rehearsals).
Level 4 (Service release) – Requirements are based on release design. Deliverable in the form of a Release Package —> Validation and Testing has to confirm that service components can be integrated correctly and that the release can be built and tested in targeted environments.
Level 5 (Component and assemblies) – Requirements in the form of a component and assembly test specification. Deliverable in the form of the built component, or assembly of components —> Validation and Testing has to confirm that the service component or assembly of components matches the detailed specification.
Service testing through service transition
Even though there are different tests throughout the Service Transition process, I’d like to point out that we differentiate between two distinct test types: verification tests – to confirm that the service is performing as designed before its release into the live environment, and validation tests – to confirm that the service is performing within the live environment as designed. In practice, the test types overlap the different levels of testing to provide a full range of testing across the service lifecycle.
Figure 2 – Example of different service tests through service transition (SORT = Service Operational Readiness Test)
Deployment Readiness Test – its purpose is to ensure all deployment processes, procedures, and systems can execute deployment in a manner that will end up with a new or changed service in the live environment.
Service Management Test will ensure that service performance can be measured, monitored, and reported once it is released into the live environment. It’s a very important part of service testing that often gets neglected.
Service Operations Test – its purpose is to check the ability of the service operation team to operate the service in production. From my personal experience, this part of testing is almost nonexistent, as the operations team is usually expected to be able to operate anything you throw in their general direction.
Service Level Tests are performed, in most cases, in conjunction with functionality tests, as functionality is often related to service level, and vice versa.
User tests will verify the end user’s ability to access and use the new service, as well as their ability to contact the Service Desk regarding the newly deployed service.
Service Provider Interface Test, as the name suggests, verifies interfaces to the service.
Deployment Verification Test is conducted in order to ensure that service capability has been correctly deployed for each deployment group or environment.
Service validation and testing is one of the value generators
Service value comes from multiple sources, but validation and testing is one of those tangible value generators, as it ensures that the service will perform according to expectations and as agreed with the customer. It will also check our own capabilities to transition the service (and its components) into operation, as well as our capabilities to operate it under defined constraints and within the budget.
Unfortunately, in reality, only a handful of IT providers approach service testing according to best practices, and Type I and Type II service providers (internal and shared service providers) are even less dedicated. This phenomenon may be understood if we take the general maturity of IT organizations into consideration, which is very low, meaning that a lack of service lifecycle processes is preventing them from delivering true value generated by service management practices.
If the situation is similar in your organization, this shouldn’t discourage you; au contraire – by understanding what you may be missing, it should motivate you and your organization to embrace best practices in IT service management, and start reaping the benefits.
To implement ISO 20000 easily and efficiently, use our ISO 20000 Documentation Toolkit that provides step-by-step guidance for full ISO 20000 compliance.
