Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Service Virtualization: The Missing Piece for Continuous Testing in Microsoft VSTS

DZone's Guide to

Service Virtualization: The Missing Piece for Continuous Testing in Microsoft VSTS

Teams are under pressure to deliver more innovative software faster than ever. Compromising on quality to accelerate a release is not an option.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Today's DevTest teams are under pressure to deliver more — and more innovative — software faster than ever before. Now that most organizations are relying on software as a primary interface to the customer, compromising on quality to accelerate a release is not an option.

Unfortunately, there's no silver bullet for delivering "quality @ speed," but one essential element is to have unrestrained access to a trustworthy and realistic test environment (i.e., including the AUT and all of its dependent components). Otherwise, you can't accurately and thoroughly validate the change impacts associated with each user story, or be confident that the evolving application doesn't degrade the overall user experience. Access to a complete test environment not only helps you achieve greater velocity; it also enables you to assess the risk of a release candidate during the CI and CD process and identify high-risk release candidates early in the delivery pipeline.

However, with today's complex systems, this type of test environment access is the exception rather than the rule. Although it was once common for organizations to stand up a local physical staged test environment, the complexity of modern applications has made that approach too slow and cost-prohibitive for today's development processes. Moreover, in many cases, it is downright infeasible due to dependencies that can’t be reproduced in the test environment.

With technologies like Microsoft Azure (for elastic scalability), Microsoft Visual Studio Team Services (for build and deployment automation), and Parasoft Service Virtualization (to simulate and access dependencies), there's no reason why a complete, realistic test environment should be out of reach.

MicrosoftAzureVSTS.png

By taking advantage of a Microsoft ecosystem with VSTS and Azure, organizations gain immediate access to scale and bandwidth. This provides the resources needed to enable flexible and ubiquitous access to application stacks that are under your control for DevTest purposes.

What about the dependent system components that are beyond your scope or control (e.g., third-party applications, SAP, mainframes, not-yet-implemented services, etc.)? This is where service virtualization comes in. You can simulate their behavior using Parasoft Service Virtualization—eliminating the final test environment access gap that commonly impedes teams' testing efforts.

The combination of Microsoft Azure, Microsoft VSTS, and Parasoft Service Virtualization — operating natively within the Microsoft environment — enables organizations rapidly deploy a complete test environment on demand. The most realistic dependent components available at that specific point in time are aggregated from a central repository and then provisioned automatically. The "most realistic set of dependent components" is often a combination of both real components and simulated components delivered via service virtualization.

These simulated test environments are lightweight and Azure-compatible so that when you need to scale (i.e., for performance testing), you can do that on demand. They are also disposable. A test environment can be instantly provisioned from a golden template, used and dirtied, then simply destroyed. There's no need to spend time resetting the environment or test data to its original state. The exact same environment can be instantly spun up whenever it's needed (i.e., for reproducing or verifying defects).

A Technical Look at Service Virtualization With Microsoft Azure and Microsoft VSTS

To streamline and accelerate the provisioning process, you can take advantage of Microsoft Azure and Microsoft VSTS to automatically deploy disposable test environments onto servers running in the cloud—making complete test environments available in a matter of seconds. The following diagram shows one way that you can use Microsoft Azure and Microsoft VSTS to rapidly deploy a complete test environment in less than 10 minutes:

microsoft-service-virtualization.png

Here's a quick overview of how the service virtualization and environment-focused steps can be configured (we're assuming you already understand how to deploy your AUT).

Parasoft Service Virtualization servers can be automatically deployed to cloud-based Azure VMs that have been allocated by Azure Resource Manager. This not only streamlines installation but also provides elasticity and scalability.

"Golden copies" of simulated test environments are defined using Parasoft's browser-based interface. A system diagram helps you define a complete environment, including all dependent components. You then leverage simulation technologies to coach the environment to behave in certain ways.

For example, assume you have the following environment for a sample banking application. From a single Parasoft environment, you can leverage simulation technology to configure the behavior of the system environments. It would be highly time-consuming to achieve this with the actual applications.

ScreenShot2655.png

Any of the various "golden" environment instances can then be automatically deployed to your Azure VMs at any phase of the Microsoft VSTS pipeline. 

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
agile ,continuous testing ,service virtualization ,microsoft vsts

Published at DZone with permission of Erika Barron-Delgado, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}