Testing is a funny role sometimes. You can be prepped and ready to go, test plans written, data prepared and everything poised for testing to begin.
Then nothing happens.
A critical API hasn’t been delivered. The SAP environment is being used by another team. A third-party system is unavailable. So, you wait. Sometimes for days. Often for weeks.
Meanwhile, the project deadline gets closer, the budget continues to burn and risk starts growing. The testing window shrinks, defects become more expensive to fix and work that should have been spread across several weeks is compressed into a few frantic days.
Your project keeps spending money, but it isn’t buying progress. Testers can’t move forward, training can’t start, expensive environments sit underused and problems remain undiscovered.
But none of this is inevitable…
We Have Normalised a Needless and Expensive Problem
I’ve never understood why businesses accept waiting as a normal part of software delivery. They invest heavily in people, automation, infrastructure and DevOps pipelines, but still allow access to one system to bring an entire project to a halt.
In most industries, this would be treated as a serious capacity problem.
Yet software teams routinely wait for shared environments, pay for restricted third-party access and build temporary workarounds. When testing finally starts, defects emerge at their most disruptive and expensive to fix.
Can any project really afford weeks where costly resources produce nothing?
Fortunately, you no longer need to.
These Days, It’s Easy to Make Unavailable Systems Available
Instead of waiting for a payment gateway, mainframe, SAP module or unfinished API, teams can work against a virtual version.
Service Virtualisation creates realistic virtual versions of unavailable, unfinished or expensive systems in your development environments.
Development and testing can run in parallel. Performance engineers can apply load without risking a critical system. Trainers can use realistic scenarios without exposing live data or paying transaction charges. Teams can also reproduce unusual errors, slow responses, interruptions and heavy load whenever required.
I know what you’re thinking, but this is completely different to rudimentary stub and mocking.
Service Virtualisation Is Not Just Mocking
A basic mock usually returns a few predefined responses for a particular test. Useful, but limited.
OpenText Service Virtualization can model dynamic data, state, errors, latency and load, then make that behaviour reusable across teams and projects. It supports a wide range of common technologies and protocols, integrates with delivery pipelines and allows virtual services to be managed centrally.
Better yet, it doesn’t require a lengthy transformation project.
It is easy enough to solve one immediate bottleneck, flexible enough to reuse widely and sophisticated enough for meaningful functional, integration and performance testing.
The Savings Go Far Beyond Testing, Cost, and Time
Virtual services can reduce duplicated environments and third-party test charges while allowing multiple teams to use scarce systems, without competing for access. Testers can also find integration problems while they are still relatively inexpensive to correct.
The results can be game-changing:
- Sky uses around 300 virtual services across more than 25 test environments, saving hundreds of staff hours.
- A large European bank created more than 150 virtual services now identifies 30% of defects earlier in pre-production.
It’s easy to see the value when you compare the licence investment with the continuing cost of waiting, duplicating environments, buying third-party access, compressing test cycles and fixing problems late.
It might sound daunting, but the process is really quite simple. Plus you can start small and build out.
Start With Whatever Is Keeping You Waiting
Don’t try to virtualise everything. Find the dependency creating the greatest disruption, calculate its true cost, then virtualise that one service and measure the difference.
OpenText Service Virtualization turns wasted time into testing time, limited systems into reusable services and project overhead into productive capacity.
If one unavailable or expensive system repeatedly holds up your projects, Calleo can help you identify whether it is suitable for OpenText Service Virtualization and demonstrate a small pilot.
