Every big software project hits the same wall. Your team builds one part of a system, but it can only be tested against five other parts. One is still being written. One belongs to another company and charges for every test call. One runs on a mainframe that is only free at night. So testing waits, and waiting is where schedules go to die.
Service virtualization exists to break that wall, and Rational Test Virtualization Server was one of the products that made the idea mainstream in large companies. This guide explains the idea in plain words first, then the product itself: where it came from, how it works, and what IBM calls it today.
What Service Virtualization Is
Service virtualization means building a working copy of a service your software depends on, and testing against the copy instead of the original.
A service here is any piece of software that answers requests over a network: a payment API, a bank’s account system, a shipping calculator, a database. The virtual copy listens on the same address style, accepts the same requests, and sends back believable responses. Your application cannot tell the difference.
Teams reach for a virtual service in three common situations:
- The real service does not exist yet. The other team is still building it, but your testing should not wait for them.
- The real service is hard to use. It is shared by twenty teams, often busy, sometimes down, or only available in short booked windows.
- The real service costs money or carries risk. A third party may charge per call, or testing against the live system could touch real customer data.
A close cousin is the sandbox environment, a safe playground copy of a whole system. The difference is scope: a sandbox copies an environment, while service virtualization copies one dependency at a time, exactly where your test needs it. If the wider idea of checking software is new to you, our guide to software testing basics covers the ground it stands on.
Mocks, Stubs and Virtual Services
Testers fake dependencies at three levels, and the words are often mixed up. Here is the simple split:
| Approach | What it is | Effort | Realism |
|---|---|---|---|
| Mock | A fake object inside one test that records how the code called it | Low | Low |
| Stub | A small stand-in that returns fixed, pre-set answers | Low to medium | Basic |
| Virtual service | A network copy of a real service, with data and behavior rules, shared on a server | Higher | High |
A mock lives inside a single unit test. A stub is a little scripted reply machine. A virtual service is the full stage double: it stands in a real environment, speaks the real protocol, and behaves well enough that whole systems can rehearse against it for weeks.
What Rational Test Virtualization Server Is
Rational Test Virtualization Server, usually shortened to RTVS, is IBM’s server for hosting virtual services so that an entire team, or several teams, can test against them at any time.
The split of work matters. Testers design the virtual services in a companion tool, Rational Integration Tester, and then publish them to the server. The server runs them day and night. A web console, the Rational Test Control Panel, acts as the shared library where virtual services are stored, started, stopped and handed out to different test environments.
IBM’s own documentation describes the product in dry but honest words: it is software for creating, maintaining, publishing and running message-based stubs and database stubs, used to simulate parts of an environment when the real services are not yet available, or are difficult or expensive to use. That one sentence is the whole product, really. The rest is engineering to make it dependable at enterprise scale.
IBM’s guides document virtualizing web traffic over HTTP and HTTPS, raw TCP connections, REST APIs, messaging middleware such as IBM MQ, and databases through JDBC stubs. Virtual services can be built by recording real traffic, or from API definition files such as Swagger and RAML documents when no live system exists to record.
How It Works: Record, Model, Deploy
The daily workflow has three moves.
1. Record
Point the tool at the real service while it still works, and capture real requests and responses. IBM calls this the Recording Studio approach. If the real service does not exist yet, you skip recording and start from the API contract instead, the same document the building team is coding against.
2. Model
Turn the recording into a virtual service. This is where the craft is: deciding which parts of a response should change with each request (an account balance should follow the account number, for example), adding realistic delays, and teaching the copy how to behave on bad days, not just good ones. A good model acts like the real service on a slow day, a busy day and a grumpy day.
3. Deploy
Publish the finished virtual service to Rational Test Virtualization Server. From that moment it belongs to the team, not to one tester’s laptop. Anyone can point their system at it, and the control panel keeps track of which version is running where.
Where It Fits: Integration Tester and the Test Workbench Family
RTVS never worked alone. It was one piece of IBM’s Rational Test Workbench, a bundle of testing tools sold to large organizations. The pieces divide the work like this:
- Rational Integration Tester is the workbench where tests and virtual services are designed, recorded and edited. Think of it as the workshop.
- Rational Test Virtualization Server is the stage where the finished virtual services perform, available to everyone.
- Rational Test Control Panel is the shared library and control room that stores virtual services and deploys them into test environments.
- The performance tools in the same family generate heavy load, often aimed at the very same virtual services, so a system can be stress tested without stressing the real third party.
If your estate is Java based, the clients driving these tests often live in an application client container, which is one reason IBM aimed this family squarely at enterprise Java and mainframe shops. More guides like this one live in our software development category.
A Short, Verified History
The product did not start at IBM. It started at a British company called Green Hat, founded in 1996 in London. Green Hat built two tools that matter here: GH Tester, for testing tangled message-based systems, and the Virtual Integration Environment, which simulated the systems a test depended on. Its customers were the kind of organizations with the worst testing bottlenecks: big banks, airlines and telecom companies.
On January 4, 2012, IBM announced it would acquire Green Hat, with no price disclosed. The tools joined IBM’s Rational software division and were renamed in the Rational style. GH Tester became Rational Integration Tester, and the virtual environment server became Rational Test Virtualization Server. IBM’s support pages show the product shipping through versions 8.6 up to 9.2.1 under that name, as part of Rational Test Workbench.
The Honest Current Status
Here is the part many older articles skip: you cannot buy a product called Rational Test Virtualization Server today, because IBM renamed it.
In December 2023, IBM rebranded its whole Rational testing line under the DevOps Test name, and an IBM community announcement confirmed that existing licenses and entitlements carried over. IBM’s release notes then applied the new names from version 11.0.0:
- Rational Test Virtualization Server is now IBM DevOps Test Virtualization
- Rational Integration Tester is now IBM DevOps Test Integrations and APIs
- Rational Test Control Panel is now IBM DevOps Test Virtualization Control Panel
- Rational Test Workbench is now IBM DevOps Test Workbench
The current product page, IBM DevOps Test Virtualization, sells the same core idea in modern language: emulate services that are not yet built or available, test earlier, and keep a central, reusable library of virtualized environments. The current documentation runs at version 11.0.x under the DevOps Test Workbench name.
So if a job post, a contract or an old test plan mentions Rational Test Virtualization Server, it means this product in its older uniform. The name changed. The job it does did not.
Benefits and Limits
The benefits are the ones IBM has sold for a decade, and they hold up when the tool is used well:
- Testing starts earlier. Teams stop waiting for dependencies and test in the first weeks of a project, when bugs are cheapest.
- Nobody queues for scarce systems. One shared server replaces the booked, fought-over test environment.
- Costs drop in specific places. No per-call fees to third parties during testing, and no full copies of expensive systems to maintain.
- Nasty cases become easy. A virtual service can be told to answer slowly, return errors, or send back strange data, on demand.
The limits deserve equal print:
- A copy can drift from the original. When the real service changes and the virtual one is not updated, tests start passing against a comfortable lie.
- Models need gardeners. Recordings and rules take real maintenance as systems evolve.
- It is enterprise software. Licensing, installation and training fit organizations with many teams and systems, not a two-person side project.
- It is not the final proof. Sensible teams still run real end-to-end checks before release. Virtual services buy speed during development, not a verdict at the end.
A Worked Example
Picture a retailer rebuilding its online checkout. The new checkout must talk to three things: a card payment service run by an outside company that charges a small fee for every test transaction, a warehouse system that another team is still building, and the company’s own order database.
Without virtualization, the checkout team waits. The warehouse API does not exist, and every full test run against the payment company costs real money, so testers ration their runs and bugs hide until late.
With Rational Test Virtualization Server in the middle, the week looks different. The team records a day of real payment traffic (with test card numbers, never real ones) and models a virtual payment service from it, including the awkward replies: card declined, bank timeout, duplicate charge warning. For the warehouse system, they build a virtual service straight from the API contract the other team published. Both virtual services are published to the server, where the performance team uses them too, flooding the checkout with a thousand fake shoppers while the fake warehouse answers at a realistic pace.
The real payment service still gets its careful, final check before launch. But by then, the surprises are supposed to be gone, because the team has been rehearsing against faithful copies for months.
Who Uses It
The natural home of this product, and of DevOps Test Virtualization today, is the large organization with a tangled estate: banks running message queues and mainframes beside modern APIs, airlines and retailers whose systems must talk to partners they do not control, and government or telecom projects where a dozen suppliers build pieces that must fit together long before all the pieces exist.
For a small team with three services, this class of tool is usually too heavy, and a simple stub library does the job. Scale is exactly what decides it: the more teams share the dependencies, the more a shared virtualization server earns its keep.
Conclusion
The server solved a simple, expensive problem: testing should not wait for systems that are unfinished, busy or charging by the call. By recording real behavior, modeling it into virtual services and hosting them for the whole team, it turned a private trick on one tester’s laptop into shared infrastructure.
The name now belongs to history. The same product line continues as IBM DevOps Test Virtualization, with the same record, model and deploy workflow at its heart. If you meet the Rational name in the wild, read it as a signpost to that current product, and judge the idea on its merits: a faithful copy, honestly maintained, is one of the most useful things a testing team can own.
