What Is Service Virtualization? Tools & Testing Examples

Service Virtualization Definition

As a critical component of many of our customers’ testing strategies, we tend to get lots of questions about service virtualization. Here are some explanations.

Service virtualization provides teams with easy access to the constrained components that impede development and testing. This usually manifests as environmental constraints, in which components that are technically out of scope for testing are required in order to enable full end-to-end functionality.

With service virtualization, you can remove these constraints by simulating those downstream dependencies and swapping out the real functionality with emulated behavior. When done correctly, the system behaves just as if the actual component was available.

Thus, you can eliminate scheduling constraints by providing ubiquitous access to an accurate emulated test environment. And you can eliminate process bottlenecks by providing rapid access to evolving, unavailable, or otherwise difficult-to-access dependent systems. As stated by Wikipedia’s service virtualization entry, these dependent systems might be:

• Not yet completed
• Still evolving
• Controlled by a third-party or partner
• Available for testing only in limited capacity or at inconvenient times
• Difficult to provision or configure in a test environment
• Needed for simultaneous access by different teams with varied test data setup and other requirements
• Restricted or costly to use for load and performance testing

Wikipedia’s entry continues to describe this well:

Rather than virtualizing entire systems, it virtualizes only specific slices of dependent behavior critical to the execution of development and testing tasks. This provides just enough application logic so that the developers or testers get what they need without having to wait for the actual service to be completed and readily available.

For instance, instead of virtualizing an entire database (and performing all associated test data management as well as setting up the database for every test session), you monitor how the application interacts with the database, then you emulate the related database behavior (the SQL queries that are passed to the database, the corresponding result sets that are returned, and so forth).

Why Is Service Virtualization Important?

To achieve quality at speed, it’s essential to have unrestrained access to a trustworthy and realistic test environment. It’s important to recognize that a complete test environment includes the application under test (AUT) and all of its dependent components such as APIs, third-party services, databases, applications, and other endpoints.

Service virtualization enables DevTest teams to get access to a complete test environment, including all critical dependent system components, as well as alter the behavior of those dependent components in ways that would be impossible with a staged test environment — enabling you to test earlier, faster, and more completely. It also allows you to isolate different layers of the application for debugging and performance testing.

Getting Access to a Complete Test Environment

With today’s fast-paced iterative development cycles, DevTest teams need early access to a complete test environment in order to:

• Validate each user story’s functionality as soon as it is completed
• Validate each user story’s impact as soon as it is completed
• Perform more comprehensive testing earlier in the process
• Complete their own DevTest tasks even if another team is implementing or evolving a dependent component in parallel with the current iteration

Service virtualization can provide access to any dependent component that is missing or constrained in your test environment: 3rd-party services, APIs, databases, mainframes, ESBs, and other components that communicate using common messaging protocols. Prime candidates for service virtualization include dependent components that are both:

• Moderately (or more) difficult to access for testing—for example, due to scheduling conflicts, access fees, licensing, geo-political boundaries, etc.
• Moderately (or more) complex to configure for testing

For example, an internal service might be readily accessible from a staged test environment and simple to configure. On the other hand, a complex message queue is probably more difficult to stand up in a staged test environment and considerably more challenging to configure for test. At the extreme end of the spectrum, a mainframe or ERP system will have multiple constraints associated with DevTest access as well as distinct limitations on your ability to configure it for test. Leveraging service virtualization ensures that a test environment is accessible on demand. It eliminates the access constraints and reduces the overhead associated with repeated configuration. Teams can test virtually without limits.

Altering the Behavior of Dependent Components

Service virtualization also gives you control over the behavior of the dependent components. It is very difficult to alter the configuration of the network or hardware associated with each dependent component of the AUT. It’s also quite common to face staged test environments that exhibit slower performance than you’d encounter in production.

Using service virtualization, you have greater control over how dependencies respond. This gives you on-demand access to a much broader range of dependency behaviors (just like a flight simulator). As a result, you can assess the risk of a release candidate faster and more accurately.

For example, you can simulate different dependency behavior to:

• Check how your AUT responds to performance variations in dependencies. Can users complete core transactions even when one dependency experiences high latency? Do low-latency scenarios expose concurrency issues?
• Isolate the component under test to understand if unexpected behavior stems from problems with dependencies or from your AUT
• Set the complete test environment into different states and validate your AUT’s security and resiliency in those contexts

Altering the Data of Dependent Components

Virtual services do not need to always respond with the actual data in the real system. In fact, there are many benefits to providing unexpected data from your virtual services. Virtual services are separated from their data sources, which allows much greater flexibility in generating response data that suits different teams needs, such as:

• Development teams that want to guard against malformed responses or negative behavior in their application can generate service responses that provide negative behavior.
• Testing teams that want to validate how non-nominal responses are handled by the service can return illegal characters in the response.
• Performance teams that want to understand the impact of large payload responses can provide larger-than-normal responses from dependent components.

By simulating the different service data in these types of situations, you can gain much more flexibility with your testing.

Practical Benefits of Service Virtualization

Of course, we’ve just scratched the surface here. There are many benefits of deploying service virtualization in your organization. Businesses that use service virtualization report fewer defects, better test coverage, greater test execution rates, and dramatically less time spent testing.