Businesses are increasingly adopting continuous delivery (CD) as a way to deliver high-quality software on demand—and to stay ahead of the competition.
But to successfully adopt CD you must be able to determine the quality of your software product at all times and at all stages in your development and delivery pipeline. And to do that, you need to be doing continuous testing. That's not easy to accomplish, but service virtualization can help you get there.
Continuous testing has its own critical success factors, including:
- Continuous text execution: You must successfully implement test automation to minimize the duration of your feedback loop. Automated tests offer deterministic, reliable insights into application quality.
- Continuous test data: You must have an efficient test data management strategy in place, meaning that you must have the right data available or be able to provision it on demand.
- Continuous test environments: You should be able to spawn, configure, and access test environments on demand in order to support your continuous testing activities.
These three success factors all require significant effort and expertise. Service virtualization can help by representing realistic behavior for a given service when the actual service is not available. With service virtualization you don't need to create multiple, redundant environments. Instead, you test service dependencies virtually.
Too often, however, decision makers dismiss service virtualization out of hand as being too expensive. There is, however, a clear business case to be made.
Even if you're sold on the benefits, you may need to debunk a few myths that can make it hard to get a service virtualization initiative off the ground with the folks holding the purse strings.
Why service virtualization is still a 'hard sell'
Once most testers and developers see what service virtualization can do, they understand the benefits. The challenge lies in selling the idea to people in control of the IT budget. There are two key reasons why budget decision makers think twice before green-lighting an investment in service virtualization.
The pain just is not big enough
A development team might adopt service virtualization as a way to replace the building of stubs. At first blush, this might seem like a good investment. Developers can spend their time doing more valuable things, such as building or testing new features that the customer values. But that's not good enough for people who control the budget.
If your team already delivers quality software on time, what reason would the decision makers have to invest in additional technology, even if there are significant gains to be had with service virtualization?
Unclear return on investment
It's often hard to calculate a return on investment for service virtualization. For example, what is the cost associated with a test environment for a third-party dependency when you're not able to simulate the behavior required for specific test cases? And how do you quantify the benefits of being able to configure your own data sets for testing, instead of having to rely on those provided by an external test environment?
In some cases, the ROI calculation can be simple. In one organization where I implemented service virtualization, we reduced the amount of time it took to set up the test data for end-to-end test cases from one week to less than one minute, and we made this change within a single week using service virtualization. We reduced the duration of test cycles from weeks to days, and that's easily quantified. Unfortunately, that's the exception rather than the norm. The ROI calculation usually isn't that obvious.
The three benefits of service virtualization
To communicate the business value of service virtualization, focus on the benefits it brings to software testing and, by extension, to the overall software development and delivery process. There are three key benefits:
1. You can test earlier
Having access to a simulation of a critical yet hard-to-access dependency allows you to start testing software earlier—which means you can deliver products earlier and earn revenues faster. Nowhere is this more the case than when you're trying to test against an application or application version that doesn't exist.
During one recent project, my team was asked to test whether an application would hold up against third-party applications that used different versions of a standardized interface. Whenever a new iteration of the interface definition was released (which happened a few times per year), there was a significant lag time before even one of the third parties had upgraded its software to comply with the latest interface definition version.
But by creating and using a simulation that acted like the latest version, we were able to test our own software's integration and compliance with the latest definition. That made the actual integration test, when the third parties delivered their own updated versions, a smooth and quick exercise. By using the simulation, we were able to front-load our testing efforts.
2. You can test more
With service virtualization, you have full control over your test data and the behavior exerted by your simulation. That means you can add to your simulations those negative and edge cases that are hard to set up or recreate with the actual dependencies. And that means fewer problems and fewer dissatisfied customers who might turn into lost customers.
For example, let's say you want to test how your application handles the situation when a third-party application serves up an invalid Social Security number. With actual third-party applications, it would be difficult, if not impossible, to ask them to return an invalid number for testing purposes. Simulation is the only viable option.
Or say you want to test how your web store handles time-outs when communicating with a third-party payment provider. Would it be easier to ask PayPal to switch off its test environment on a regular basis or to create a simulation that you can take down yourself, test against, and then turn back on at will?
3. You can test more often
Once you have your test environment and all of the dependencies in it under your control, the spawning, using, and destroying of test environments and dependency simulations becomes a highly automated, repeatable process. This means that you're no longer limited to testing once or twice per development cycle using a suitable test environment with all required test data in place.
Now you can execute not only your unit tests (which are often heavy users of mocks, another form of simulations), but your integration and end-to-end tests on demand. Creating and provisioning a test environment that behaves exactly as you want, and as your tests require, becomes just another step in the build process with service virtualization, especially when served inside containers such as Docker. You can shorten the feedback loop to a minimum and deliver software faster, tested at all levels.
Service virtualization: The investment is not as big as you think
Service virtualization has a reputation for being too costly. While it's true that license fees for enterprise-grade service virtualization services aren't cheap, the payoff often warrants the investment.
Also, now that service virtualization is gaining traction, better and more mature open-source solutions (such as Hoverfly and WireMock) are slowly becoming mainstream. Commercial service virtualization providers are also taking stock. For example, Parasoft released a community edition of its Virtualize software, which allows development teams to use enterprise-grade service virtualization software without the license fees normally associated with such a tool. It's not a trial, but a "free forever" version.
Get your service virtualization game on
The expanding range of more reasonable options means you can achieve the benefits that service virtualization brings to the testing and development process without breaking the bank. And with the ever more distributed nature of software applications, combined with the need for delivering quality software fast, the demand for service virtualization will only increase.
You need simulated test environments for successful continuous testing and continuous delivery, and service virtualization is the way forward. So build your business case and get started.
Do you have questions about how to convince budget decision makers about business benefits of service virtualization? Post your questions here and I'll do my best to answer them.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
