Stickyminds Logo
Published: April 10, 2017 – by Alexander Mohr, Cynthia Dunlop – at

If you’re like many of the leading enterprise testing teams today, you’ve already recognized the need for test automation and committed to ramping up your test automation efforts. You may have even made significant progress toward automating primary use cases that cover your top business risks. But then you reached an automation plateau.

Shortly after you built your initial automated test suite and started executing it regularly—potentially as part of a continuous integration effort—your dependencies created a roadblock. You need the dependent system components of the application under test (AUT) to be available in the test environment whenever your tests are executed.

However, with complex enterprise systems, at least some of the many required dependencies are commonly incomplete, unavailable, or operating incorrectly at the time of test execution. Some might have changed versions, and others might be using inaccurate or expired test data. The result is timeouts, incomplete tests, false positives, and inaccurate results—preventing you from delivering the fast quality feedback expected with test automation.

Service virtualization can help you overcome this plateau and increase test automation rates.

What Is Service Virtualization?

Service virtualization is a simulation technology that lets you automatically execute tests, even when the AUT’s dependent system components (APIs, third-party applications, etc.) cannot be properly accessed or configured for testing. By simulating these dependencies, you can ensure that your tests will encounter the appropriate dependency behavior and data every time they execute.

Service virtualization is commonly used when integration tests or end-to-end tests need to interact with dependent system components that are:

  • Unreliable, evolving, or not yet completed
  • Beyond your scope of control (e.g., operated by another company or division)
  • Available for testing only in a limited capacity or at inconvenient times
  • Challenging to provision or configure in a test environment
  • Simultaneously needed by different teams with varied test data setups and other requirements
  • Too restricted or costly to use for automated regression testing

Read More…