<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=1110556&amp;fmt=gif">
January 24, 2022

Continuous Service Virtualization, Part 1: Introduction and Best Practices

by: Shamim Ahmed

Introduction

Service virtualization (SV) has evolved as a popular technique and technology over the last decade. Traditionally, SV has primarily been used by testers to simulate other application components that the application under test interacts with. Typically, virtual services have been created and maintained by center of excellence (COE) teams.

This meant that such efforts were often isolated from other personas, such as developers, test data engineers, deployment engineers, release engineers, and so on. For example, developers typically use programmatic techniques (such as mocking and stubbing) to support their unit and component testing efforts, and such assets are not re-useable by testers (and vice-versa). Similarly, test data engineers fail to leverage the synergies between virtual services and test data. In addition, deployment engineers fail to leverage virtual services to simplify and automate the provisioning and deployment of their environments.

With the increased adoption of DevOps, continuous integration (CI), continuous delivery (CD), and continuous testing (CT) practices, SV activities can’t continue to be performed in isolation, as they traditionally have been. It is imperative to integrate SV efforts with other activities in the CI/CD/CT/DevOps lifecycle to enable better collaboration and frictionless agility. This new approach to SV is what we call “continuous SV.”

This is the first of a two-part series of blog posts on continuous SV. In this blog, we will describe some best practices for establishing continuous SV as part of DevOps. In our second post, Continuous Service Virtualization, Part 2: Steps for Optimizing DevOpswe will discuss four key steps for leveraging continuous SV to optimize collaboration and flow in the DevOps lifecycle. 

What is Continuous Service Virtualization?

“Continuous” SV is derived from the principle of “continuous everything” in DevOps. Continuous SV is a key component of CD within the DevOps framework. With this approach, SV activities are embedded across the different phases of the CI/CD lifecycle, as opposed to being employed in a single “testing phase.” SV activities are performed collaboratively by different personas, such as developers, API engineers, testers, deployment engineers, and so on. As assets are progressively built and maintained, they are shared by these different teams. (See figure 1 below.)

Broadcom Enterprise Software Academy – Continuous Service Virtualization, Part 1: Introduction and Best Practices

Figure 1: Continuous SV concept

Key Practices for Continuous SV

The following are the key practices that enable continuous SV.

Shift-Left SV Definition Activities

As with most activities in the CI/CD lifecycle, continuous SV also requires that most of the SV work (such as specification of virtual services, and virtual service generation, updates, and maintenance) “shifts left,” so it happens mostly during the CI part of the DevOps lifecycle. This minimizes the delay that SV processes can cause during the CD part of the lifecycle, helping to speed deployment cycle time. (See figure 2 below.) We will describe what SV activities happen in each stage of the lifecycle later in this blog.

Broadcom Enterprise Software Academy – Continuous Service Virtualization, Part 1: Introduction and Best Practices

Figure 2: Continuous SV along the CI/CD pipeline

Adhere to the Test Pyramid: Use Progressive Virtualization

The test pyramid is one of the key tenets of shifting testing left. This means that more and more SV processes need to support tests in the lower half of the pyramid, for example unit, component, integration, and component tests. (See figure 3 below.)

Broadcom Enterprise Software Academy – Continuous Service Virtualization, Part 1: Introduction and Best Practices

Figure 3: Mapping types of virtual services into the test pyramid

This also influences the type of SV approach we use:

  • For the vast majority of unit and component tests, which are typically run by developers, we need to use lightweight, synthetic virtual services (aka mock services). Such virtual services are created synthetically (as opposed to recording a real service) using various techniques, such as by defining request-response (RR) pairs for an API, for example. This is important in the development phase, as the dependent service may not yet exist in order to be recorded. However, developers can easily create a mock service for the dependency based on its API specification. Mock services may be augmented using synthetic test data to provide support for a wider range of behaviors in the virtual service. See more on the interplay between virtual services and test data management in the following section. 
  • For the vast majority of tests in the middle tiers of the pyramid, such as integration, contract, and system tests, we recommend hybrid virtual services. Hybrid virtual services are a mix of synthetic and recorded virtual services (when dependent services already exist). These virtual services would be complemented by hybrid test data, which is a mix of synthetic and more realistic test data, which is created by taking a subset of data from production and masking it.  Typically, these tests (as shown in Figure 2) are run in the CD part of the DevOps lifecycle. This means that such services must be created ahead of time and provisioned and deployed into the appropriate test environment, along with the application binaries and other test assets, such as test scripts and test data.
  • For most end-to-end, business process, and user acceptance tests, we need to provide more realistic virtual services that are created from service recordings. This is practical since we expect most endpoints to exist by this phase of the lifecycle. Such services will be complemented by realistic test data that is most commonly obtained from production environments.

Note that the test pyramid applies not just to functional tests, but performance tests as well. The reason we point this out is that virtual services play a key role in performance testing at all levels. It does so by emulating not just the functionality of the endpoint, but also the performance of the dependent endpoint, so that the performance of the target application can be tested completely.

Use Progressive Virtualization

To map the needs of virtual services to the test pyramid, we need to use “progressive virtualization” (see figure 4 below). Progressive virtualization means that we first build simple lightweight synthetic virtual services (which are the easiest to create) for the development/unit test part of the CI/CD lifecycle. As we move from left to right along the lifecycle, our virtual services progressively become more realistic to support the latter stage tests—using more robust test data scenarios and/or using recorded virtualization for services that have been implemented by that stage.

Broadcom Enterprise Software Academy – Continuous Service Virtualization, Part 1: Introduction and Best Practices

Figure 4: Progressive virtualization

This is different than the traditional mocks and stubs that developers create for unit testing. These traditional elements are often not re-used by testers (for latter stage tests) or by other developers. On the other hand, in the case of progressive virtualization, the same lightweight virtual services are progressively (or continuously) enhanced, re-used, and shared with multiple teams, which improves the productivity of all teams.

Use a Virtual Service Catalog and Gateway 

Re-use of virtual services in progressive virtualization, as described above, is supported by the use of an integrated service catalog and gateway (See figure 5 below). An SV catalog provides a centralized repository for sharing and managing virtual services across teams and applications. In addition, using a gateway allows parameterized access from clients to different versions of the virtual service (or a real service if available, for example in pre-production testing) without changing the client code.    

Broadcom Enterprise Software Academy – Continuous Service Virtualization, Part 1: Introduction and Best Practices

Figure 5: Continuous SV with Service Catalog

Use Service Virtualization in Conjunction with TDM

Continuous test data management is a key practice for enabling CT. When complemented with test data, virtual services enable tests to be more robust in their ability to support a greater range of scenarios and interactions with the simulated endpoint. 

In fact, the type of test data used (whether synthetic, hybrid, or production-like) correlates with the extent of service virtualization used. At the bottom of the test pyramid, we aggressively use both synthetic test data and virtual services. Towards the top of the pyramid, we use more realistic test data with real application components. We can use hybrid approaches for the middle tiers.

When using virtual services for test data, we need to make sure that we maintain consistency between data used to drive the tests, the application database, and the virtual service. The first two are typically taken care of by test data management (TDM) tools. For the virtual service, we need to either record or synthesize the virtual service with the same data set used for the test. (See figure 6 below.)

Broadcom Enterprise Software Academy – Continuous Service Virtualization, Part 1: Introduction and Best Practices

Figure 6: Synchronizing test data with virtual services

Integrate SV with CI/CD Processes

In order to achieve continuous SV, we need to ensure that the provisioning and deployment of virtual services are also automated along the CI/CD lifecycle. As discussed in the previous section, this is especially important in the CD part of the lifecycle, where we need to minimize elapsed time to reduce cycle time. This can be achieved by integrating the deployment of virtual services with deployment automation tools. For applications that are deployed in containers, we may package test assets (including virtual services) in side-car deployment containers and deploy them alongside application containers.

Conclusion

In this blog we have discussed what continuous SV is and its key practices. In the following blog, Continuous Service Virtualization, Part 2: Steps for Optimizing DevOps, we will discuss the continuous SV lifecycle and how it helps to optimize DevOps.

 

 

Explore More Posts

View All Blog Posts
May 25, 2022

What's New in Test Data Manager 4.10?

This latest release lets customers deploy TDM at scale, facilitate migrations of SAP applications and operate across a wide range of databases. Read Now
April 22, 2022

Register Today for Our "What's New in Test Data Manager 4.10" Webinar

Learn how the new release lets you deploy TDM at scale, facilitate migrations of SAP applications, and operate across a wide range of databases. Read Now
February 21, 2022

Continuous Test Data Management for Microservices, Part 2: Key Steps

This post, the second in a two-part series, outlines the key steps for applying continuous test data management in microservices environments. Read Now
February 16, 2022

Continuous Test Data Management for Microservices, Part 1: Key Approaches

This post, the first in a two-part series, looks at key concepts for applying continuous test data management (TDM) to microservices environments. Read Now
January 24, 2022

Continuous Service Virtualization, Part 1: Introduction and Best Practices

In this blog, the first of a two-part series, we will describe some best practices for establishing continuous service virtualization as part of DevOps. Read Now
January 24, 2022

Continuous Service Virtualization, Part 2: Steps for Optimizing DevOps

In this second post in our two-part series, we discuss four key steps for leveraging continuous service virtualization to optimize the DevOps lifecycle. Read Now
November 3, 2021

Employing Agile Requirements Designer to Support API Testing: 5 Use Cases

With Agile Requirements Designer, teams can create API tests that can be executed with their test automation framework. This post describes five use cases. Read Now
September 28, 2021

Optimizing Continuous Testing with Continuous Test Data Management

This blog describes some best practices for establishing continuous test data management (TDM) as part of continuous testing. Read Now
September 8, 2021

Security Testing in an Agile Development World

This blog post presents different security testing methods and provides a few tips for conducting a more secure code review. Read Now
August 26, 2021

Agile Requirements Designer Delivers Enhanced Custom Field Capabilities

ARD offers extended custom field capabilities that enable you to dynamically aggregate values from multiple blocks and export a computed value on a path level. Read Now