Service Virtualization misrepresentations abound, from “You can only virtualize small projects" to “It’s just not possible.”  Creating new ideas and ways of doing things are natural habitats for myths, so to help clear the air, the ServiceVirtualization.com team has been hard at work searching for the truth about virtual services.

Here’s our Top Ten list. Be sure to tell us what you think about our choices, or add your own in the Comment section.

“I need production data to validate that my software is functioning as expected.”

Production data is often insecure for your live customer or business purposes, but beyond that, it is also very volatile and unstable for purposes of appropriately verifying that every scenario in a regression, function or performance context is being exercised. It is far easier to have a virtual set of test data that will always represent the scenarios you need, without the hassle of dealing with production data.

“It’s better to Dev/Test against a live environment than a virtual services environment.”

Reality really is overrated. In a live environment, you don’t have the control, data reset, performance profile changes and other important components that are available in a virtual environment.

"I will get 80 percent of the value if I use virtual services on four out of five dependencies."
I’m afraid not. It is almost always an all or nothing proposition.

“My interface contracts change constantly so I'll have a bunch of virtual services to support and that will cause more overhead and confusion."


Actually, Service Virtualization resolves that issue by decoupling component development and forcing specific sync points for contracts, which keeps your team focused on the business code underneath the contract. You only have to bother with contract changes when they are more solid. This also enables specific teams to react to needed contract changes without stopping all the teams in a shared and constrained environment.

“Service Virtualization can’t perform well enough for performance testing.”


A virtual service should be an extremely lightweight simulation of a real system and very responsive under real world load conditions to hundreds or thousands of transactions per second. There’s no disk image, OS or network latency to slow them down (but you can of course, slow the responses down if you want to simulate a performance lag on the other side).

“Virtual services are just test stubs that you can make yourself.”



While you can code your own stubs, once you get past very simplistic behaviors the effort and cost of mocking up all the systems you depend on throughout the software development lifecycle becomes overwhelming. Service Virtualization demands automation in that the simulation and modeling can be conducted by direct observation on the part of software rather than requiring manual coding and adjustment. Otherwise, you may be spending as much time maintaining your stub environments as you do building and testing the application functionality itself.

“You aren't really making sure your stuff works until you test it with real back end systems.”


That’s like telling a pilot that you won’t be using a wind tunnel or flight simulator to test an aircraft. He’ll be the one giving that newly designed jet its first real test - with a load of passengers. It’s the same thing with software. You don’t want your customers taking your new system out for its initial test flight.

"My systems are so complex and unique that you can’t build a virtual service for them.”


Service Virtualization does not attempt to recreate or understand the logic or intelligence behind your system. Think of an SAP instance with thousands of database tables and hundreds of message queues behind it, or a telco provisioning system – which can be unbelievably complicated – both have been virtualized several times over. When you create a virtual service, you don't care what happens behind the scenes, you just observe the requests and the responses and play them back in a stateful way (i.e. maintain a conversation). It's not the real thing but it's good enough to develop and test against. You have just faked it out with something cheap.

“I deal with secured / SSL / encrypted data and Service Virtualization can’t handle that data.”


In fact, the exact opposite is true. Service Virtualization automates the masking of sensitive data, which allows testing to proceed without exposing data to unauthorized users or processes.

“It’s just not possible.”

Hundreds of the world’s largest and best known companies have a rich history using Service Virtualization to develop high-quality applications faster and cheaper. If you have any doubt that virtual services can solve real-world problems, just review this list.