Although many development and QA professionals understand concepts such as server virtualization and virtual machines, not everyone has been exposed to the concept of “service virtualization.” Service virtualization allows you to virtualize software components such as SOAP or REST web services calls, message queues, and other components. Service virtualization provides many benefits, so it is worth understanding how it can save your team time and money.
In a nutshell, service virtualization allows you to mock or spoof various systems in your enterprise, so that:
- You are not delayed by internal teams or third parties.
- You may eliminate the need to build infrastructure for development and testing.
- You can isolate behaviors during development that allow you to capture all cases that might not easily appear organically over a shorter time frame in production.
Typically, service virtualization is set up between your application endpoints and the production endpoints. It self-learns by recording actual calls and builds a series of requests/responses that can then be modified and expanded by the development and QA teams. It provides features far beyond simple mocking and should be part of any enterprise-level software development project.
Use cases
A simple use case demonstrating where service virtualization provides value is for an enterprise application that consume a third-party web service that you pay for, such as a credit or a vehicle identification number (VIN) check. If the service you consume charges $10 per call for the data it provides, testing this service can get expensive.
Similarly, you may have a use scenario where you need a response with certain credit rating from certain city/state, and some other parameters. It is easier to create that specific response with service virtualization than combing through thousands of unsorted credit bureau test accounts to find a matching one. With devops becoming a necessary and mainstream activity, as outlined in Isaac Sacolick’s book, Driving Digital, the expectation is that test automation runs every time the developer checks in code.
No one wants to be in the position where he or she has finally implemented devops, only not to be able to afford to run multiple test runs per day, or mitigate the risks associated with inconsistent test data. Here, service virtualization allows you to do make calls against the virtualized service and return valid responses to your battery of automated test cases, saving both costs and downtime due to unreliable infrastructure.
Another related case involves test and development environments. Often, service-level agreements exist with your vendors for production environments, but the test environments—whether in your own organization or with the vendor—often do not have the same level of service as production, and as a result, are nonresponsive more often than production.
You may also be in a situation where the vendor’s delivery has been delayed due to problems on their end, or their systems goes down every Tuesday and Thursday for maintenance at a time of their choosing. Instead of your teams sitting idle, they can use service virtualization to create the appropriate responses that would be returned from the production service, so development and testing can continue.
Many readers with children have had similar conversations to me, where I explain that though putting the ATM card into the machine results in money returned to me, I must work to earn the money—it doesn’t just appear. Unfortunately, many of us tend to think of our infrastructure teams as the ATM of servers and environments. But, much like the bank, someone must budget for, buy and build the servers. The software that runs on them also has a cost, as does the configuration and integration. Service virtualization, in a number of cases, can be set up to mimic some or all of what would need to have been purchased and built, but at a cost far less.
Service virtualization can also be used to support performance testing. With service virtualization, you can isolate specific portions of your application under test without needing to worry about stressing other pieces system that are your concern for the test objective.
Setting up service virtualization is not overly complicated, and a technical QA or development team can easily get it up and running without requiring professional services from the vendors. The costs are not extreme either, and when you include the reduction in hardware, reductions in license fees and project schedule time savings, service virtualization pays for itself many times over. If you are not already using this technology, this would be a great goal for 2018 to further support budget reductions, decreased time to market, and devops.