HP Service Virtualization
EOH provides an approach to reducing the time, cost and risk in delivering new applications by working with clients to minimise test environment downtime and the costs of providing such environments. One of the approaches used is to virtualize services in order to simulate dependant applications and therefore remove them from the complexity of managing and maintaining the test environment. This is part of a series of articles on the why, how, what and when for the growing discipline of service virtualization.
Your Services Virtualized
HPs Service Virtualization acts as one or more applications when testers are trying to check the quality or performance of composite applications. Similarly developers building applications dependant on service calls to other systems can unit test their code earlier in the lifecycle as we can make simulated services available in a consistent fashion.
If we use this approach then we no longer need to include expensive or third-party systems in the test environment specification which provides major benefits in cost avoidance for environments. More importantly there should be a reduction in lost testing time and cost as the virtual services are more stable and easier to manage.
SV is worth looking into further if you have composite applications that are under development or need testing and you have any of the following problems:
- Third party application costs for test or development
- Problems booking time on test environments such as mainframes or ERP systems
- Lost time due to internal or external environment downtime
- Blocked development and testing due to waits on environment builds
want to find out more?
Five Types of Applications Ripe For Service Virtualization
Service virtualization is an approach to delivering better test outcomes by providing cheaper, more relicable and flexible test environments. For more on the concept see part 1 of the blog, Service Virtualization – The Concept. As with any automation deciding on the right applications and services to automate is key to maximising the long-term return on investment. Here we have outlined five important criteria to consider and why.
#1 – Expensive related applications and infrastructure
Some applications are simply too costly to replicate in multiple test environments which means that either they are only available in key environments or rationed such as mainframes or large ERP applications. Where this is the case building out additional temporary environments using approaches such as application virtualization is not an option. Service virtualization can simulate these environments which frees up options in terms of creating test environments and allowing integration testing earlier in the application lifecycle.
#2 – Third party systems and interfaces
There are multiple challenges around testing composite applications with third party systems: limited compatible data with your applications, third parties charging for test transactions and a loss of control around system availability. Service virtualization can help avoid third-party costs by simulating the responses from these services while still retaining the ability to provide the same expected response times as the target service. The accurate simulation of response times is key to understanding the performance of composite applications which is something that has been traditionally difficult to achieve with simple test stubs.
#3 – Shared systems
Applications or data that are shared across multiple systems can prove challenging to manage as often test teams need the systems to be in different states in order to achieve their testing objectives. For example the CRM team need to test assigning products to new customers but the billing team want to run a batch job on the same underlying data. Using service virtualization these test activities can be decoupled with a resulting reduction in testing time and cost as neither team are blocked by other activities in their test environment.
#4 – Small-scale infrastructure
The scale of performance testing environments are traditionally quoted as barriers to effective performance testing as production sized environments are too costly or a production issue means that an environment is sequestered to resolve a problem. This means that performance testing is often late in the project or limited in accuracy so performance issues find their way into production. Service virtualization can simulate the response from legacy and third party systems with detailed performance models to help get a more accurate handle on the performance and scalability of composite applications.
#5 – Undeveloped systems
It is difficult for development and QA teams to check application quality where entirely new services are being built to support an application. Project delays are caused by dependencies on new services being built and deployed which can be avoided by virtualizing the service. Services can be created using the service definitions before the real service is deployed so development and QA can concentrate on delivering their applications in parallel with other project streams or third-parties.