Service Virtualization – Shift Left Testing

Everyone agrees that the sooner we find defects in the application development life cycle, the better it is. This calls for shift left approach for testing, where in, we conduct as many levels of testing as early in the life-cycle and as often as possible. Agile development, CICD (Continuous Integration and Continuous Deployment), stubbing and service virtualization (a more matured version of stubbing) are among the chief instruments currently popular in the industry for implementing shift left testing. In this article we will briefly touch upon stubbing and service virtualization

Stubbing

As mentioned already, we would like to conduct as many levels of testing as early in the life-cycle as possible. However, when we are in early stages of development, System and Integration testing may not be possible as some of the application components may still be under development, some interfacing systems may not be available. Stubbing used to be the approach for closing such gaps – where in, dummy components are created and stood up in place of components and interfaces that are not developed yet or are not available for some reason. The diagram below shows this conceptually - application components 1 and 4, one upstream and one peer systems are not available, hence stubs are created to stand in their place.

However, stubbing has several limitations. It is more of a reactionary activity (i.e. created as and when need arises) than a planned/systematic activity. Often the stubs are created discreetly, using different technologies, owned, deployed and maintained by multiple teams with little or no visibility across teams, with no centralized management or control. We tend to lose track of the stubs once the release is done and/or resources who created those stubs move on to another project or move out of the company.

Service Virtualization

Service virtualization replaces the fragile stubs and mocks with dynamic, robust simulations that accurately model the behavior, data and performance of needed systems.

Although service virtualization may seem like a glorified version of stubbing, it is superior in terms of speed of development, deployment and maintenance. Many of the problems associated with stubbing mentioned above are now addressed by service virtualization. Tools such as CA DevTest Service Virtualization, Parasoft Service Virtualization, and IBM Rational Test Service Virtualization and many open source tools and technologies help you implement service virtualization. These tools simulate not only the “to be built” components of the system, but also upstream, downstream and peer systems and interfaces that are usually readily not available in lower environments. Service Virtualization is particularly impact full in lower environments (Example: system environment) as it facilitates higher levels of testing (Ex: Integration testing/End to End testing etc.) thus effectively enabling shift left testing. It will also minimize impact on testing due to shortage of environments, interfacing applications having their own release timelines. Applications built on micro-services or service oriented architectures are especially suitable for service virtualization. It is an important aspect of modern application development where the desire is to shift testing to left.

In addition to shift left testing, service virtualization addresses several other problems in lower environments, such as - avoiding costly pay per call type of third party services, resolving conflicting needs for different versions of same service by different applications in the organization, emulate systems with restricted access due to sensitivity, security, privacy or other reasons

As you can see in picture above, with service virtualization, the brittle, discreetly and sporadically deployed stubs have been neatly organized, deployed and managed centrally. As applications progress from lower to higher environments, the actual interfaces will take over and the role of virtual services will diminish gradually. However, they can come in handy any time needed since they can be configured to work with different environments and deployed quickly should the need arise thus giving the flexibility with environments and delivery timelines.

Service Virtualization is a niche and technically complex area and available commercial solutions are quite expensive. Expertise is also somewhat hard to come by. It is highly recommended to conduct a PoC with the help of experts in that space before investing on a commercial tool or implementing an open source solution.