You can't truly accelerate the SDLC without a dependable continuous testing process. Evolving from automated to continuous testing requires on-demand access to a complete, realistic test environment. Yet, such access can be extremely difficult to achieve with today's increasingly complex and interdependent applications. Consider these recent research findings from voke:
On average, organizations require access to 33 systems for dev/test, but have unrestricted access to only 18
Only 4% of participants report immediate, on-demand access to dev/test lab environments
The majority of participants wait days or weeks to gain access to lab environments
These constraints frequently slow or stop the progress of development (44%) and testing (68%)
Attempting to increase test environment access by building out staged test environments with conventional infrastructure can be extraordinarily expensive. One way to cost-effectively eliminate these constraints is to combine service virtualization with cloud-based virtual dev/test labs to deliver complete, production-like simulated test environments:
All the systems that your organization can logistically image in the cloud are copied into an elastic cloud-based dev/test lab.
Those beyond the team's scope or control (e.g., third-party applications, SAP, mainframes, not-yet-implemented services, etc.) are simulated into the environment via service virtualization.
Dev/Test Cloud and Service Virtualization: Parts of a Complete Breakfast
"Take any system that you need to have ready for testing, but is not readily available. It could be a heavy mainframe that is too bulky to image as a VM, or a third party service you don’t have the access permission to copy. It would be much easier if you could realistically simulate just the behavior and data you need to run tests with those components.
Enter Service Virtualization (or SV), which gives us a lightweight way to eliminate these constraints by replacing them with Virtual Services. This new technology is rapidly becoming a standard practice in large enterprises, with several major vendors offering solutions in the space. SV is proven to “cut the wires” of dependencies in dev/test environments.
That’s great for traditional on-premise environments, but it is especially useful in cloud dev/test scenarios, where speed is of the essence. Cloud infrastructure has come a long way in the last few years as well – offering increased capacity and performance at decreasing cost. But there will always be some components that just don’t make sense to port directly to cloud.
In many cases, you don’t need, or even want the real thing in your dev/test cloud. Production systems may respond and perform unpredictably. If you are developing an application that will talk to production systems, you will likely need to suss out all the boundary conditions in your battery of tests. For instance, what if the mainframe responds in 30 seconds instead of 3 seconds, or .3 seconds? What if my partner’s service returns my form request with an unknown error, or a bunch of SQL hack statements?
It takes too much work and coordination to try and make every other team’s system respond exactly as you want. But you can easily make a virtual service do what you want. Better to focus on the aspects of development testing, integration and performance testing that are in the scope of your requirements, and automate the rest."
[TECHNICAL PAPER] Parasoft Service Virtualization and Skytap Environments as a Service
Want to learn more about how using service virtualization in concert with virtual dev/test labs helps teams rapidly configure, provision, scale, and reproduce complete dev/test environments? Read the technical paper Delivering 24/7 Access to Complete Test Environments. You'll learn how your organization can gain
A fast and cost-effective means to create and maintain the required test infrastructure.
Cloud-based, self-service access to complete test environments (including proper network configuration) across distributed teams and partner ecosystems.
The elasticity needed to accommodate fluctuations in team size and/or test resource needs (e.g., for performance testing or parallel regression tests).