Creating virtual services from actual transactions in your environment is the best way to build virtual services that emulate the real behavior of live services. To do so, your service virtualization solution should be able to capture traffic from your environment either natively or through integrations with solutions like Wireshark or Fiddler, enabling non-technical users to capture specific use cases into virtual services without intimate knowledge of the real back-end services.
- AI-powered asset creation
If your service virtualization solution has intelligence built into the asset creation process, it will be able to make decisions about things you commonly do when creating your virtual services.
- Test data management/generation
Often the services that are identified as candidates for service virtualization are actually suffering from data challenges, so test data management and service virtualization go hand-in-hand.
In addition to creating virtual services, your service virtualization solution can generate the test data you need, tightly coupled with your test data management/generation solution so that you can capture data from your environments, mask that data for privacy reasons, abstract transactions into a data model, and then generate and subset data in those models.
Your service virtualization solution should be able to emulate APIs using Representational State Transfer (REST). This includes support for service definition such as Open API (OAS 3), Swagger, or RAML. Your tool should also be able to simulate URL, method, path, parameter, query, and JSON payload information as well as emulating headers, mime-types, attachments and so on.
Your service virtualization solution must be able to interface with SOAP APIs, including support for service definition such as WSDL and schema/.XSD.
- Asynchronous API messaging
Especially for reactive microservice environments, your service virtualization solution should be able to act asynchronously (send requests and responses without waiting for a corresponding reaction.
To dynamically deploy virtual services as a function of code check-in, your service virtualization solution should be able to integrate into your existing CI process.
Many CI pipelines take advantage of build systems such as Jenkins, Microsoft’s Azure DevOps, Atlassian’s Bamboo, Jet Brain’s Team City and many more.
If your service virtualization solution can execute via command-line invocation, you will be able to dynamically start and stop your virtual servers as needed when running your test cases.
Management and maintenance
As your service virtualization initiative scales, it will be important to set up a governance process around usage, defining roles, responsibilities, access levels, policies, procedures, SLAs, naming standard and more so you can build a center of excellence that can handle a large volume of incoming virtualization requests without becoming a bottleneck.
Once you’ve built a large inventory of virtual services, your service virtualization solution should help you manage virtual test environments with a self-service interface. Users should be able to define what virtual services are connected to particular workflows, as well as what configuration is required to enable test automation of that flow.
Successful service virtualization is based on users trusting that their virtual services are behaving the way they expect, so monitoring is essential.