service virtualization
What is service virtualization?
Service virtualization is the process of creating replicas of systems that new applications depend on to test how well the application and systems integrate. It is primarily used for integrating applications that depend on cloud and service-oriented architectures or applications that communicate with third-party data and APIs. Examples of these systems include customer relationship management services such as Salesforce Service Cloud, enterprise resource planning services such as SAP ECC, and internal systems that are still in development.
Developers can implement a virtualized replica of the dependent system so integration testers can see how well their application integrates. This lets development teams save money and time by testing throughout the development process. Otherwise, they would need to wait to test integration until these dependent systems are available, which might take a long time because a third party controls them or they are still in development.
Unlike server virtualization, service virtualization only replicates specific interfaces, interactions and behaviors -- situations wherein a server might interact with an application -- rather than a complete server.
How does service virtualization work?
Service virtualization tools monitor traffic between the dependent system and the application. They use log data to build a model that can replicate the dependent system's responses and behavior, using inputs such as SQL statements for databases and XML, or Extensible Markup Language, messages for web services. As developers test the new application, the virtualized service produces the same responses that the real one would.
Developers use this simulation to test how a new application, service or feature integrates with existing infrastructure. Service virtualization removes a significant development bottleneck by ensuring testers don't have to wait to begin testing. This allows teams to release products with fewer defects, on time without disrupting service.
Testers can also build in special cases that simulate high traffic volume or slow connections. Once the application is ready for integration, developers can replace the simulation with the real thing.
Service virtualization vendors and products
Parasoft developed one of the first products with service virtualization functionalities in 2003, but ITKO invented the term in 2007. Major players have since developed or acquired their own service virtualization tools. IBM acquired Greenhat, CA Technologies acquired ITKO and Hewlett Packet Enterprises developed its own technology. Other companies that offer service virtualization tools include Hoverfly, Traffic Parrot, WireMock and SmartBear.
Benefits of service virtualization
Service virtualization benefits are most acute in rapid deployment and continuous delivery scenarios. It let teams rapidly iterate on test results throughout the development process, which is beneficial to DevOps and Agile teams. Service virtualization helps these teams prevent bugs during development, build better systems with fewer defects and share responsibility for testing the quality of the product across departments.
Benefits of service virtualization also extend to companies outside of these rapid workflows. For example, if an organization wants to upgrade its back-end systems, it might risk downtime-causing integration problems once those systems come back online. With service virtualization, developers can test the back end as they improve it and test its interactions with the front end before full integration.
Service virtualization lets developers keep up with application development even when there are missing components. Before service virtualization, testers needed to wait for applications that were nearly complete. Different teams with different schedules, priorities and requirements would often need to finish and assemble the application before the testers could access it.
The rapid, integrated testing that service virtualization enables helps development teams meet their deadlines and get the product on the market faster. Testers can catch a potentially disruptive problem earlier, which helps development plans remain on schedule. Service virtualization also lets organizations avoid setting up expensive testing labs.
Disadvantages of service virtualization
Disadvantages of service virtualization include cost and implementation. Budgeting for service virtualization implementation can be difficult because its usage crosses many different departments. It can be difficult to assess who has ownership over testing and who should oversee service virtualization.
Additionally, service virtualization doesn't replace full integration testing with the actual dependent systems. Service virtualization enables integration testing throughout the development process, which speeds the final testing, but a final test process is still necessary.
Service virtualization vs. mocking and stubbing
Mocking and stubbing are like service virtualization, but they function on smaller scales. Mocking and stubbing usually involve testing specific behaviors in restricted contexts, whereas service virtualization replicates systems at a production scale.
The growing popularity of service-oriented architecture and Agile development exposes limitations to mocking and stubbing. Service virtualization approaches testing at the infrastructure level and creates models that different teams can reuse in different circumstances. Mocks and stubs typically require manual development for each use case. Service architectures typically require too many dependent variables for mocking and stubbing to be practical, and Agile workflows demand a speed that these methods struggle to meet.
Beyond that, developers are more likely to introduce errors into stubs and mocks based on their assumptions of how the application is supposed to react in each situation. Quality assurance teams can integrate both technologies if they use service virtualization when they need to emulate systems and mocking or stubbing when they only need simple, context-specific unit testing.
