The sentence we hear most often in enterprise test environments is: “The tests are ready, but the dependent system is down.” Core systems, third-party APIs and services still in development often set the testing schedule more than the application itself.
Service virtualization represents these dependencies with controlled models. But not every dependency needs to be virtualized. We see three situations where the investment pays back fastest:
- The dependent system’s test environment is often unavailable or shared between teams
- Third-party calls are paid, rate-limited or restricted for testing
- Scenarios such as timeouts and faulty responses are hard to reproduce on the real system
The right starting point is a measurement, not a tool. Work out how many days testing waited on dependencies over the last few releases. That number tells you which services to start with and how large the investment should be.
For virtual services to keep their value, ownership must be defined from the start. If nobody knows who updates the model when the real service changes, virtual services quickly lose credibility.