Roadmap: How to Adopt
This roadmap describes how to adopt the Service Virtualization practice.

Getting Started

In the traditional approach to development, all the components to be delivered must be completed by the system integration tests or the user acceptance tests.  All the components must be ready for the system or for users to execute end-to-end tests in order to find defects.  Defects can be found in both these instances of end-to-end testing.  If more of the system was available before running end-to-end tests, defects could be found earlier.  Traditional end-to-end testing finds defects only when the entire system is available, late in the development process.

Rethink your approach to testing with service virtualization.  Emulate dependent, yet unavailable, software and test integrations earlier.  With service virtualization you do not need to wait until all of the application components are available to execute end-to-end testing.  

Virtualized Testing Adoption Patterns

Continuous Testing

Automated integration testing is used to provide repeatable, efficient testing at the integration level (“inside the box”).  It is implemented by an organization to reduce costs for creating virtual services.

An existing application component(s) under testing within an environment is recorded to capture the independent behavior. From the recording, a virtual service(s) is generated and used in place of the component(s) behavior for testing other components or applications.


Existing Service Virtualization

The virtualization of a specific service or services is used to solve a dependency on an unavailable or non-functional software component or application which is holding up progress on the critical path of a project.  It is implemented by a project or release to mitigate dependencies and perform testing without actual dependent components.

During the software development process, component and application teams develop changes to software at different rates and times. Differences in timing when specific features or functionality is available is not usually synchronized to support integration testing provide It is usually not feasible to coordinate the changes across components in order to support continuous testing for each component with all of the component versions that contain the needed changes and interaction. [see Paul Bahrs email for correction]

One or more of the dependent application components are represented in the test environment as a virtual service. The scope of the service is sufficient to support the planned test cases. Individual developers, component teams or a centralized COE may develop these virtual services as needed or as a part of the release or project planning phase. The virtual services are published to a centralized server to provide for reuse and to be automatically enabled during application deployments. 


 

Virtualization For a Specific Release or Project

The virtualization of some or all of the services or interfaces in a system is used to meet a team, project or release specific need and to provide for reuse. A typical example being 100 services virtualized in a system comprising 15 applications to enable integration testing both for the whole system and for providers who are upgrading or maintaining individual applications.  It is implemented by an individual developer, teams, project, or releases.

A developer from any of these organizations develops the services either manually or by monitoring and recording an existing test environment. Services are published for use across the organization requiring the virtual service. For individual or team creation, virtual services are published for reuse.


Enterprise Virtualization

Enterprise virtualization is used to establish an enterprise capability to virtualize services for all projects/releases and to reduce the costs or time to develop in a project/team each time it is needed.  An organization creates a central resource to provide a suite of virtualized services that can be re-used across multiple projects and lines of business.  It is implemented by a centralized team or Center of Excellence (COE). (see Virtual Service COE Builder and Virtual Service COE Lead)

A centralized, enterprise service is deployed that will provide a single point for specific virtual services. These services will usually be maintained and versioned over time and provided to project teams during testing.  The services are captured through recording or manual development and are general enough to support testing across the enterprise.


Virtual Services Center of Excellence (COE) Adoption Model

This graphic shows a typical model for deploying a virtual services COE in an organization to support the adoption models explained above.




From Discovery to Execution

The following table outlines the process for implementing service virtualization.