Introduction

In the software industry complex applications, heterogeneous systems and the cost of setting up test environments challenge an organization’s ability to conduct integration tests. The pressure of faster delivery in the agile model and the challenges involved in the complex application, having multiple interdependent components, guarantees a bumpy ride in every development life cycle.

There is one common problem where all the members of the project team stagger: Teams wait for the dependent components to get completed – without which unit tests will be feasible but not the complete system test. This is where service virtualization can come in handy and effectively improvise the process. Using service virtualization, one can emulate the essential third party components used in the application. This results in frequent and much earlier integration test in the development process. It removes the key bottlenecks which would delay production and time-to-market.

What service virtualization means to QA?

Traditionally, test engineers start their proper functional, integration, and performance testing once the AUT is completely deployed including all the interdependent components. The dependent components might be developed by distinct project teams. Sometimes there might be delays in delivering the components which leads to the incomplete working product. The testers will have to wait until all the dependent components are completed which is linear and slow process.

In times of rapid and continuous development cycles, it isn’t practical to wait for that long before testing to see how each component communicate with each other. Production services that may not be available for integration testing need to be virtualized so that the testing can take place at an appropriate time in the software development process. Service virtualization is ideal for the TDD teams in which a huge amount of time is spent testing the API layer where the major problems are often first introduced into system interfaces. Service virtualization extends its arm from small unit test to automated performance tests of an integrated system.

How does Service virtualization work?

Service virtualization is used to create a virtual asset which we can call virtual service. This is a system-generated software object containing the instructions aka “conversation” between any two subsystems involved. It is highly critical that unique software automation should be involved in capturing and modeling the virtual service otherwise we can end up in a time-consuming, costly stub coded manually.

Assume, there is a scenario where an online retailer uses third-party vendors for the payment gateways available only on the production. The teams can’t perform their regression or the performance testing of the application without this downstream-dependent component. These virtual services can be considered as a stand-in replacement for those constrained components which we don’t want to expose to the daily grind.

The virtual services are “simulating” the behavior rather than “replaying” it.  Sufficient dynamic logic must be implemented with enough intelligence and modeled into the virtual service which would cater to the variability of the needed usage scenarios.

Mock vs. Stub vs. Virtual Service

Having said about the differences between each of the components, let’s see two major components in this field :  State based verification and Behavior based verification.

State-Based verification

State-based verification inspects the state of the system under test which has been exercised and then compares it to the expected state. Mostly stubs are used in this type of verification. A test stub is a type of test double used to replace a real component on which the SUT depends so that test has a control point for the indirect inputs of the SUT. The test stubs will act as indirect inputs during test execution.

Behavior-based verification

The indirect outputs of the SUT are captured as they occur and compared to the expected behavior. The indirect outputs are the actual interaction between the SUT and its dependencies. A mock object is test double used to replace the real component on which the SUT depends on with a test-specific object that verifies the behavior of the SUT.

How has it improved software testing?

The companies that implement service virtualization for development and testing have effectively reduced the operational costs with greater software quality and faster delivery. The voke report states the following facts which are self-explanatory

• More than 25% at least doubled test execution rates
• More than one-third reduced test cycle times by 50% or more
• 36% reported a 41% or greater reduction in production defects
• 46% reported a 41% or greater reduction in TOTAL defects

Conclusion

Service virtualization has proved critical to the success of the application economy. By breaking the constraints around over-utilized systems, service virtualization can obtain a service layer that is more cost-effective and flexible. However, the challenge remains in terms of which service virtualization tool will best fit the project needs and how to implement them effectively.