Sunday 1 February 2015

Service V Model is a concept that is raised in the Service Transition volume of the new ITIL 2011 guidance and publication. The  Service V Model is a unique concept that provides a path to follow with regard to defining the requirements for a service package, designing the package, building and then testing the package. The model provides baseline points along the path that are used a checkpoints to ensure that what is being designed, built and delivered is actually what was required. Each step on the path also has specifically named outputs that should be visible.

The V-model approach is traditionally associated with the waterfall lifecycle, but is, in fact, just as applicable to other lifecycles, including iterative lifecycles, such as prototyping, RAD approaches. Within each cycle of the iterative development, the V-model concepts of establishing acceptance requirements against the requirements and design can apply, with each iterative design being considered for the degree of integrity and competence that would justify release to the customer for trial and assessment. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of
testing. During each phase of software development thought is already given to the corresponding tests. For instance, during the definition of the Service Requirements, the corresponding Acceptance tests are already written and signed off.

The advantage of the V-model is that by writing the tests at the time of specification errors in the specifications can be detected in an earlier phase, avoiding costly reworks later on. Additionally, testing happens at different levels, first component testing, then package testing, system testing etc. again leading to early detection of errors.

Using techniques such as the Service V model for Service Validation and Testing provides a framework to help organize the levels of Configuration Items that are needed and the associated testing and validation activities within and across stages of the change. The Service V Model is a concept of establishing acceptance requirements against the various levels of requirements that apply in order to justify release to the customer for trial and assessment. 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, and there is direct involvement by the equivalent party on the right hand side. It shows that service validation and acceptance test planning should start with the definition of the high level requirements. It also describes that the person/group or sign off on the requirements on the left side should be involved on the right side to accept that the requirements have been met. The actual tests required at each level should reflect the approach to risk and level of confidence that is required for the service change being transitioned. There are many frameworks and sources of guidance focused specifically on testing e.g. Test Management Approach (TMAP) that provide more details about the specific types of testing activities that can be performed. These normally include:
  • Usability testing
  • Accessibility testing
  • Process and procedure testing
  • Knowledge transfer and capability testing
  • Performance, capacity and resilience testing
  • Volume, stress, load and scalability testing
  • Availability, backup and recovery testing
  • Security testing
  • Logistics, deployment and migration testing
  • Build, packaging and distribution testing
  • Operability and maintainability testing.
Test Strategy

A test strategy describes the overall approach to organizing testing and validation, including the allocation of the enabling resources required. It may apply to the whole organization, a set of services or a single service. The typical contents of a test strategy document include:
  • The purpose, goals and objectives of service testing and validation
  • Scope and organizations
  • Applicable standards, legal and regulatory requirements
  • Service Management policies, processes and practices applicable to testing
  • Test models used
  • Test process activities (planning and estimation, documentation, control, execution etc)
  • Test metrics
  • Service Provider interfaces
  • Test criteria
  • Roles and responsibilities
  • Environment requirements
  • Deliverables
Test Models

A test model describes a test plan, the scope of a test and the test scripts that define how each element will be tested. It ensures that testing is a repeatable process and that the defined deliverables are achieved. Test models should be structured so that:
  1. There is traceability to the initial design requirements and criteria
  2. All activities can be measured and audited
  3. That test elements can be reused or changed
Service V Model is an excellent example of a test model used according to the different levels of testing and validation that apply.

Why should one use Service V Model? 
  • All of your very beautiful plans become ugly at some point. So you need reliable and proved  standards to well manage the deployment of your applications or new and changed services. 
  • In order words, you can use the same standards again and again; it can be applied in the same way across different suppliers and/or clients you may have. It is easy to fit and explain to suppliers and clients. 
  • The Service V-Model helps to mitigate risks when implementing something new in your infrastructure. So you can have fewer issues caused by unpredictable risks. 
  • It helps the team to document the customer’s requirements in a standard format; it helps to understand what your customers really want; and it helps you in estimating and funding for your business case. 
  • The Service V-Model helps managing the customer’s expectations. If some of your clients requirements are changed after you have already started your design and build; you have tools to negotiate and tell your clients how long a ‘Test’ will take to place or how long it will be delayed.
__________________________________________________________________________

Author - Vijayakumar Reddy, CTO & Lead Trainer, A2A IMTCS Pvt. LTD.

© Copyright 2014 A2A - IMTCS. All rights reserved. www.iimtcs.in
The Swirl logo is a trade mark of AXELOS Limited. 
ITIL® is a Registered Trade Mark of AXELOS Limited. www.axelos.com