Service virtualization is becoming a critical component of our customers’ testing strategies, and as such, we tend to get lots of questions about it. Here are some explanations.
In a nutshell, 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:
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).
To achieve quality at speed, it’s essential to have unrestrained access to a trustworthy and realistic test environment. It is important to recognize that a complete test environment includes the application under test (AUT) and all of its dependent components (e.g. APIs, 3rd-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, but we’re not going to get into that as much today.
With today’s fast-paced iterative development cycles, DevTest teams need early access to a complete test environment in order to:
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:
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.
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:
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:
By simulating the different service data in these types of situations, you can gain much more flexibility with your testing.
Of course, we’ve just scratched the surface here. There are many benefits of deploying service virtualization in your organization. Businesses who have adopted the cutting edge testing practice of service virtualization report fewer defects, better test coverage, greater test execution rates, and dramatically less time spent testing.
Hot tip: you can download Parasoft’s enterprise service virtualization solution for free.
A Product Manager at Parasoft, Chris strategizes product development of Parasoft’s functional testing solutions. His expertise in SDLC acceleration through automation has taken him to major enterprise deployments, such as Capital One and CareFirst.