Service Virtualization and API Testing

Cynthia Dunlop

Subscribe to Cynthia Dunlop: eMailAlertsEmail Alerts
Get Cynthia Dunlop: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Virtualization Magazine, SOA & WOA Magazine, Cloud Expo on Ulitzer, Microservices Journal, DevOps Journal

Cloud Computing: Article

ABCs of Service #Virtualization | @CloudExpo @Parasoft #SDS #DataCenter

What is Service Virtualization? How does it impact software testing Access, Behavior, Cost, and Speed?

What is Service Virtualization?
To achieve "quality @ speed", it's essential to have unrestrained access to a trustworthy and realistic test environment. It is important to recognize that a complete test environment includes the application under test (AUT) and all of its dependent components (e.g., APIs, 3rd-party services, databases, applications, and other endpoints).

Service virtualization is an emerging technology that provides DevTest teams access to a complete test environment by simulating the dependent components that are beyond your control, still evolving, or too complex to configure in a test lab. Service virtualization is commonly used when dependent components connected to the AUT are:

  • Not yet completed or still evolving
  • Controlled by a 3rd party or partner
  • Available for testing only in limited capacity or at inconvenient times
  • Difficult to provision or configure in a test environment
  • Needed for simultaneous access by different teams with varied test data setup and other requirements
  • Restricted or costly to use for performance testing and/or Continuous Testing

Service virtualization enables DevTest teams to:

  • Provide access to a complete test environment including all critical dependent system components
  • Alter the behavior of those dependent components in ways that would be impossible with a staged test environment-enabling you to test earlier, faster, and more completely
  • Isolate different layers of the application for debugging and performance testing

The ABCs of Service Virtualization are Access, Behavior, Cost, and Speed...

ScreenShot1465.png

With today's fast-paced iterative development cycles, DevTest teams need early access to a complete test environment in order to:

  • Validate each user story's functionality as soon as it is completed
  • Validate each user story's impact as soon as it is completed
  • Perform more comprehensive testing earlier in the process
  • Complete their own DevTest tasks even if another team is implementing or evolving a dependent component in parallel with the current iteration

Service virtualization can provide access to any dependent component that is missing or constrained in your test environment: 3rd-party services, APIs, databases, mainframes, ESBs, and other components that communicate using common messaging protocols. Prime candidates for service virtualization include dependent components that are both:service-virtualization-definition

  • Moderately (or more) difficult to access for testing-for example, due to scheduling conflicts, access fees, geo-political boundaries, etc.
  • Moderately (or more) complex to configure for testing

For example, an internal service might be readily accessible from a staged test environment and simple to configure. On the other hand, a complex message queue is probably more difficult to stand-up in a staged test environment and considerably more challenging to configure for test. At the extreme end of the spectrum, a mainframe or ERP system will have multiple constraints associated with DevTest access as well as distinct limitations on your ability to configure it for test. Leveraging service virtualization ensures that a test environment is accessible on demand. It eliminates the access constraints and reduces the overhead associated with repeated configuration.

ScreenShot1466.png

Service virtualization also gives you control over the behavior of the dependent components. It is very difficult to alter the configuration of the network or hardware associated with each dependent component of the AUT. It's also quite common to face staged test environments that exhibit slower performance than you'd encounter in production. Using service virtualization, you can have greater control over how dependencies respond. This gives you on-demand access to a much broader range of dependency behaviors-just like a flight simulator. As a result, you can assess the risk of a release candidate faster and more accurately.

For example, you can simulate different dependency behavior to:

  • Check how your AUT responds to performance variations in dependencies. Can users complete core transactions even when one dependency experiences high latency? Do low-latency scenarios expose concurrency issues?
  • Isolate the component under test to understand if unexpected behavior stems from problems with dependencies or from your AUT
  • Set the complete test environment into different states and validate your AUT's security and resiliency in those contexts

ScreenShot1467.png

...

Service Virtualization ABCs

Get the complete ABCs of Service Virtualization infographic to learn:

  • How service virtualization reduces DevTest costs and accelerates velocity
  • 6 signs your team could benefir from service virtualization
  • 17 things you can simulate with service virtualization

Also, if you're just starting to explore service virtualization, we invite you to join us for the Service Virtualization ABCs  webinar this Thursday (September 15). You'll learn the basics of Service Virtualization, including how it can help your organization:

  • Provide access to a complete test environment including all critical dependent system components
  • Alter the behavior of those dependent components in ways that would be impossible with a staged test environment-enabling you to test earlier, faster, and more completely
  • Isolate different layers of the application for debugging and performance testing

More Stories By Cynthia Dunlop

Cynthia Dunlop, Lead Content Strategist/Writer at Tricentis, writes about software testing and the SDLC—specializing in continuous testing, functional/API testing, DevOps, Agile, and service virtualization. She has written articles for publications including SD Times, Stickyminds, InfoQ, ComputerWorld, IEEE Computer, and Dr. Dobb's Journal. She also co-authored and ghostwritten several books on software development and testing for Wiley and Wiley-IEEE Press. Dunlop holds a BA from UCLA and an MA from Washington State University.