What Is Service Virtualization?
Service virtualization is the practice of emulating the behavior of real system components that will be
accessed by the system under test (SUT).
The Concept of Service Virtualization Explained
The concept of service virtualization is best explained using the example of a shopping site designed with a three-layer architecture (see image below). This site consists of a web front end that is connected to an application/service middle layer, which is connected to a database.
Suppose a team is testing a login process on this site. When a user interacts with the web front end and enters their username and password, the website will invoke a login API call to the middle layer. The middle layer will fetch credentials from the database and verify the user’s credentials.
If the credentials match up, then the service layer will return a “successful” message to the web front end and the web front end will proceed to the next step. If the credentials don’t match up, then the service layer will return an “unsuccessful” message to the web front end and the web front end will display an “invalid login” message to the user.
To test this simple scenario, all three components (website, application/service middle layer, and database) in the test environment must be up and running, with all security credentials in order, and the test data in the database must be ready to consume login credentials. Having a complete test environment may not always be possible for every team in every situation—especially in larger organizations.
If one team is building the service layer and the login functionality is still under development, then testing of the web front end that requires the login functionality will be blocked until the service layer is completed. In addition, other factors—such as the databases not being in the right state or security credentials being expired or corrupted—can cause the test scenario to come to an immediate stop.
With service virtualization, teams can emulate the behavior of the service layer and return the successful or unsuccessful message without actually logging into the system.
Teams can also virtualize databases and put them in the exact state that the test requires, eliminating waiting times for the environment to become stable. This makes it possible to execute tests without having the completed service layer or database in place—and it ensures consistent dependency behavior on every test.
Is Service Virtualization the Same Thing as Mocking or Stubbing?
Although service virtualization does resemble mocking and stubbing in some ways, there are key differences. Mocking is typically created by developers for their unit testing. They may build a stub that can provide a response from a dependency within a very specific process, and this stub will probably live on the desktop of the developer. It can save time within that specific use case, but it has limited usefulness beyond that.
Service virtualization, on the other hand, involves creating services that can be shared by different teams throughout all stages of the testing cycle. Virtualized services become part of the test environment or infrastructure. Once implemented, they can have a widespread impact on testing processes.
A virtualized service communicates with the same message and protocol that the real service does. Incoming requests can be correlated with commonly used data sets, expanding the virtual services’ request handling capabilities. Logic and performance characteristics can also be included in the virtual service, which can make it react more like the live service and extend its use across other teams.
Top Benefits of Service Virtualization
With service virtualization, an organization can:
1. Shift testing left
It is a best practice to move testing as early as possible because it’s easier and cheaper to fix defects earlier in the software development life cycle (SDLC). By using service virtualization to remove dependencies, teams can test more of their system even before other dependent systems are built. This ability to test early extends into non-functional testing such as performance testing, which normally is only possible in later states of the testing cycle.
- Speed up execution. Teams that often test lengthy batch services know well the frustration of waiting for a process to complete before receiving a response from the system. Service virtualization eliminates this delay. Rather than performing any processing, service virtualization only simulates the behavior of another service from the point of view of the system under test and then returns a response. This alone can shave precious time off test execution.
2. Reduce costs
Many services run on expensive hardware. The cost of servers needed to host distributed applications, databases, and sandbox environments can soon add up. Many organizations are moving their environments to cloud deployments to reduce physical costs, but are finding out that uptime and virtual machine sprawl can increase just as quickly as having physical servers.
With service virtualization, organizations may be able to remove these machines from the test environment or reduce uptime in cloud environments, thereby decreasing power and maintenance costs.
In addition to reducing hardware costs, teams can decrease the cost of software licenses and third-party services by leveraging service virtualization. For example, if a business process relies on responses from a third-party service that charges a fee per transaction, then every time a test runs, the company will incur a cost. This reality will either drive up the cost of testing or compel teams to execute tests less often, which may compromise the speed of delivery or quality of the product.
Hardware and software fees can increase quickly—and discourage teams from testing thoroughly. With service virtualization, teams can get reliable responses from virtualized versions of third-party services and decouple systems under test from the dependent systems, which will help keep testing budgets under control.
- Reduce costs. The typical testing cycle can rack up expenses related to hardware, software, personal downtime, third-party costs, and other factors.
3. Isolate issues more easily
Teams can use service virtualization to isolate components in a system under test. When testers have complete control over responses, they can verify that contracts are correct from release to release before they undergo full integration testing. This approach can quickly expose any defects in a component release. Performance tests may reap the greatest benefits from this isolation. By performing resiliency testing on isolated components, teams can discover bottlenecks in performance much earlier in the development process.
4. Reduce data preparation efforts
One of the biggest bottlenecks in setting up a testing environment is making sure that there is proper data in place. For example, a team that’s testing purchasing on an ecommerce website will need to make sure there’s adequate inventory data available. This usually involves filing admin tickets to set systems such as mainframes and databases into specific states, and may require them to work with at least one other system to prepare this data. These teams usually need to wait for tickets to resolve and are sometimes required to schedule testing windows in which these states will be available. Even with a testing window in place, there’s no guarantee that other teams might consume or modify the data unexpectedly, requiring the data prep process to have to start all over again. With service virtualization, they can simply virtualize the request and response so that they can test positives and negatives, rather than going through the exercise of creating an entire inventory database.
5. Reduce false positives
In software testing, false positives have one of three causes: environment, data, or poorly written test cases. With service virtualization, teams work in a simplified, tightly controlled environment to eliminate the possibility that testing could be hindered by the activities of developers on other teams. They also closely manage the test data they use. This leaves only test cases as a possible source of false positives.
6. Predictable negative scenario testing
Many testers struggle when it comes to negative scenarios and corner cases. Configuring negative data or getting a component to respond with a timeout or error code can be almost impossible in a real deployment. Teams can configure virtual services to generate a variety of timed responses and error codes, which will let them see how a SUT reacts.
Challenges of Service Virtualization
Like test automation, service virtualization requires some up-front work before it begins to yield benefits. This work can be more complicated than setting up automation. To set up service virtualization, teams should work with the Business, Test Architects and the System Team to understand the interactions between the different systems as well as the data that these systems are sending and receiving.
Depending on how the service virtualization is deployed, teams may need help from Enterprise Enablement to redirect to a virtual service the messages that were meant for the actual service. This is a matter of changing IP addresses. In other cases, application developers will need to add special code to enable the application to connect with the virtual service instead of the real service during testing.
Getting Started with Service Virtualization
There are three possible approaches (defined by the technology or solution used) for implementing service virtualization, each with its advantages and disadvantages.
The first is to record all the messages sent back and forth between systems in production. Based on this information, teams can then build service virtualization that simulates the responses given by actual services.
- It is relatively easy to get started; teams simply set up the system that can record the production or test environment.
- Teams can gather data and messages from real-life production scenarios.
- It may take time to gather enough messages to cover all possible business scenarios.
- The data and messages gathered from the recording may be outdated by the time the testing team uses them, which means teams will have to constantly re-record services.
- Gathering recorded messages may leave the team with a staggering amount of data to sift through—much of it irrelevant to testing. This data needs to be constantly pruned and reduced to maintain relevance.
- Even after weeks of recording messages, the team may still not end up with the exact messages they need to virtualize services effectively.
- Data gathered from recordings may be sensitive, and many organizations need to apply obfuscation to protect it. This process can add significant overhead to the testing cycle.
The second strategy is for teams to create the exact message scenarios they need for service virtualization. This process involves building response requests for every business scenario that teams plan on testing.
- The overall volume of data remains much more manageable.
- It is easier for teams to keep up with new development because they can create the desired behavior before development is even complete. Because a virtual service doesn’t perform any actual calculations, it is relatively fast and easy to build.
- Teams retain full control over the behavior of any service. They can drive all test scenarios because they define the behavior.
- Some virtual service deployments can perform logic and calculations, extending the services’ handling capabilities.
- Setting up message scenarios is more complicated than simply recording production messages because teams need to know in advance exactly what data and messages they’re looking for. Tooling can speed the process, but teams still need to have significant background knowledge before they proceed.
- The service behavior that teams virtualize may not match the behavior of the actual service. Even a very well-informed team may create message scenarios that do not reflect reality—oftentimes because the documentation of the system is incorrect. But in this case, we can return to one of the advantages of service virtualization: teams always know that the issue isn’t with an external service—it’s with the SUT.
- If a virtual service becomes too complex, it can be just as complicated to maintain as a real service.
Finally, teams can create virtual services by leveraging existing service definition languages such as Open API/SWAGGER and WSDLs.
- Virtual services can be stood up and created quickly.
- Virtual services can be versioned easily along with the definition updates.
- Virtual services will follow all the same constraints as real services because they will adhere to the same service definitions.
- To ensure that they’re creating proper virtual services, teams must update and maintain service definitions.
- Teams still need to create data sets for these virtual services.
Key Considerations for Service Virtualization
Before delving into service virtualization, teams should:
- Remember that not every service can or should be virtualized. Some services are too costly to virtualize. Others may require special tools beyond the current toolset.
- Evaluate the ROI. With service virtualization, teams can achieve hardware and licensing savings, as well as reductions in the cost of accessing third-party services. Service virtualization leads to reductions in defects and greater ease of fixing bugs. Speeding up testing and enhancing its quality can also yield financial benefits. But these benefits typically do not become apparent until teams achieve a significant amount of virtualization.
- Start virtualizing services early. Teams should ideally create virtual services of the components they’re currently working on. They can then add these services to a catalog of virtual services that is available to the greater organization. All teams can use this catalog to develop and test before the real service is released. If teams use contracts, they can establish an automated process to create these virtual services.