Service Virtualization

Made Simple with ServiceV

An Easy-to-Use Solution for Everyone on the Team
 Speed API Delivery
with Powerful & Lightweight
Service Virtualization

LEARN MORE ABOUT SERVICEV PRO

Contents
A Brief Introduction to Service Virtualization 4

Mocking is a workaround, not a solution 6

Why mocking is not scalable? 7

Need for Service Virtualization 9

Virtualization on your desktop 12

Sharing your virtual services with the team 14

Automating your virtual services 15

SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM 3
A Brief Introduction to
Service Virtualization
Software development and testing occurs in conjunction
with other activities. Most of the code that is written
and tested depends on several resources that are often
beyond the reach and control of a developer or a tester.
a payment in this scenario, the mobile app likely
integrates with several systems, including databases
and web-services (APIs). These integrations allow you
to get items, make the payment, and ultimately place
the order. Many of these resources are in your control
but many others are not, because theyre owned
by other teams. Such resources are called third-party
dependencies.

For example, say you are developing an e-commerce For example, a typical list of third-party dependencies
mobile app that lets you browse items and make may look like the following:

Resource Owner Availability

Database Yourself Always available

User Profile API CRM Team Still under development

Inventory API ERP Team Only in production

Payment API Payment Gateway Needs a credit card

Ordering API Order Management Team Available, but with rate limits

SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM 4
As you can see in the above table, not all the dependencies
are under your control. Often while developing code you
will reach a point when you must use these third-party
dependencies and interact with them. One example might
involve getting data for a customer profile screen. If these
dependencies are not ready and responsive, you will have
to stop working on the code that call them. Often, to work
around this, developers will write functions or methods
that return a hard-coded API response. This is not ideal,
as the hard-coded values are valid for just one scenario
and not reusable, this also encourages bad code writing
practices. Similarly, a tester testing functionality that
depends on other unavailable resources will be forced Develop and Test in Parallel
to skip testing until that resource is available, adversely
impacting test coverage.
with Service Virtualization
Unavailable dependencies create issues for developers
and testers as they limit the amount of development
GET STARTED IN MINUTES
and testing that can be done. Without full availability of
dependent resources and services, all possible use cases
do not get covered. This results in limited unit testing and
many of the test cases do not get executed at all. Often
these dependencies cause bottlenecks. Teams have to
pause their work because theyve come to a point where
they absolutely need the actual third part services. Without
them, its not possible to get any work done at all.
SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM 5
Mocking is a workaround,
not a solution
Mocking provides a way to emulate the missing resource,
especially APIs, while testing or developing a software.
Mocks are very basic setups that are created on code or
on tools that can mimic, for example, a few API calls. This
allows the development and testing teams to do a very
basic level of testing using these emulated calls.
Generally, mocks are created by development teams in
code, and run for their own development and testing.
Mock creation for users who are non-developers is
difficult: testers often use open source tools for creating
mocks and if they dont have strong coding skills, theyll
find this very hard to do. There are not many easy to use
open-source tools available for mocking.
A good example of an open source tool that allows testers
to create mocks is the open source version of SoapUI.
However, as it is an all-purpose API testing tool (rather
than one focused solely on mocking or virtualization), it
doesnt make it easy for testers to scale and adapt mocks
to multiple testing scenarios.
SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM
Its important to understand that any test that is
being conducted must be easily scalable to multiple
scenarios. The reason of this is that, as your testing
becomes more complex, the scenarios become more
complicated. For example, initially testing a phone
number API might be as simple as fetching a phone
number and asserting (a concept used in testing,
where you assert a response parameter against a
predefined value) the phone number format. But as
the business case scenario becomes complex, you
may have to test against different variations of phone
numbers they might be from other countries, or
contain special characters. To test these scenarios,
you need to have API mocks that are capable of
responding with different permutations of phone
numbers, and unless your mocking solution supports
easy and scalable creation of mocks, youll find it hard
for you to configure it for all these permutations.
6
Why mocking is not
scalable?
Mocking does not support quick creation of scenarios
for testing at a moments notice. Mocking can be very
personal, as its hard for developers or testers who
have spent a lot of time creating these mocks to share
their work with their peers.
Another problem with mocking is that it is stateless. This
means that its very hard for a tester to setup common
information (parameters) that can be used across all the
mocked responses. For example, if you are testing a banking
transaction, then you may want to take the name of the
customer and the bank account number across all mocked
API responses. Unless your mocking tool supports this, its
very hard to set this information up and ensure that it gets
passed through all the test cases. You will end up spending
hours just to set up the wiring mechanisms to do this.

Problems with mocking

1. Mocking needs 2. Mocking needs

scripting and coding manual configuration
(its cumbersome) (needs a lot of work)

Mocking

3. Mocking does not 4. Mocking is not for

scale to all scenarios everyone and teams
(not scalable) (not collaborative)

SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM 7
Another challenge with mocking is that it is heavily reliant
on code its usability depends heavily on the skill of
the developer or tester creating the mock. Most of the
mocking tools available on the market right now are based
on scripting and coding hence it becomes very difficult for
a tester or a person who lacks coding skills to think about
developing a mock for their testing purposes.

Another issue is that most of the testers and developers

working with APIs spend most of their time working on A scalable, scriptless solution
the front end. Thus, their knowledge of API technology
and specifications is limited. A modern-day API is built for service virtualization
on protocols like XML and JSON, also using specifications
like SOAP and Swagger, and unless you have knowledge
about these protocols and specifications it would be hard
TRY SERVICEV NOW
for you to build a mock around them. Because a usable,
functional mock requires creating detailed requests and
responses, it requires the ability to understand JSON and
XML, and to parse values in and out of them. It would be
hard to create a sophisticated mock without the support
of a tool that does the heavy lifting around working with
these protocols and specifications.

SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM 8
Need for Service Virtualization
Service virtualization has recently become popular along
with up-and-coming processes like Agile and DevOps. It
allows sophisticated and real life emulation of a service that
is either unavailable or hard to access.
Recently in our State of Testing survey we found that 72%
of the testers are testing against APIs which are owned
inside the organization. So, most probably you are testing
against a service that belongs to a team next door and
due to issues around communication with the teams,
accessibility to artifacts and unfinished work you are not
able to use these services for your own development
and testing. Service virtualization plays an important role
here by providing real life simulations of these services
for your testing and development purposes. This reduces
dependencies and friction between teams and improves
collaboration in the long run.
In the survey 28% of the respondents said that they test or
develop against external or third party services like Goo-
gle maps. These services are often expensive or the rate
at which the service can be utilized is throttled (controlled)
by third-parties, and is therefore inadequate for day to day
testing and development purposes.
SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM
To help visualize what this looks like, use the following
example. Say you are developing an e-commerce
application and you are integrating with a payment
gateway. In this case, it would be difficult to repeatedly
test a credit cards transaction functionality without
making a payment with your credit card. However, if
you could accurately emulate the payment gateway
service and test or develop off it, you could test your
e-commerce application as many times you wanted
without any restrictions or a fear of being charged.
In addition to this, there are many other reasons for
unavailability of third party services. A few of them are
captured below:
Still under development
Undergoing maintenance/update
Difficult to set-up for testing or development
Owned by third parties
Too costly to use (paid APIs like Google Maps)
Restricted access (due to geography or security
restrictions)
9
One important thing to remember is that a third-party
service does not always have to be an API. A service
could be a network service, a telecommunication service,
or a database. A service virtualization solution could
help you emulate any of the services that your software
development or testing depends upon.
Its always useful to list all the services that your software
or testing process depends on and build a back-up plan
catering to the uncertainty of availability for each. Once
you have a plan for each of the dependencies, then every
time these dependencies become un-available you can put
that plan in motion. With a virtualization solution in place,
you would be able to quickly spin up virtual services and
continue your development and testing even though a
service is unavailable.
With increasing competition and the advent of Agile and
DevOps, the pressure has increased on teams to deliver
faster and more frequently, unavailable services often
creates bottlenecks that cause teams to stop working.
This result in unnecessary delays in the delivery of the
application to the market, and in many cases, dilutes any
productivity effects that adoption of best practices like Agile
and DevOps have had on the overall delivery time lines.
SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM
Unlike mocking, which requires manual configuration
and scripting, service virtualization enables quick and
easy creation of virtual services. Services could be
created by providing API specifications or recording
service traffic with just a few clicks. In ServiceV Pro
developers and testers can use a built-in UI recorded
to access websites, isolate the backend API calls and
create virtual services out of them. With one virtual
response created, its very easy for developers and
testers to clone and customize it for different use cases.
For even more flexibility and scenario coverage, virtual
responses can be linked to data elements from a data
source like Excel or a column in a database like My-
SQL and Oracle. Beyond this, service virtualization also
enables emulation of network conditions like limited
bandwidth, as well as hardware conditions like small
capacity servers, that are hosting the service, being
virtualized.
10
 Mocking API Calls Virtualizing APIs
Static implementation for specific
Full implementation of the service
situations

State-less, responses do not have State-ful, Responses are aware of the

contextual information context

100% manual configuration No configuration needed

No re-use Re-usable artifacts

Difference between Service Virtualization and Mocking

These features enable testers and developers to create
realistic environments for their development and testing.
With very few clicks, they can record an API response, link
the elements in the response to a set of scenarios in the
database, and quickly use them to develop and test even
when the actual services are not available. ServiceV Pro
also enables quick switching between the virtual and the
actual service so if the developer or tester needs to hit the
actual API, they could do so the just a flip of the switch.
For these reasons, service virtualization solutions en-
able teams to move faster, work continuously, and de-
liver on time, without being delayed due to bottlenecks
caused by other teams and services. The net result of
using service virtualization is that teams have better
control over their testing and development environ-
ments and they can quickly customize these environ-
ments and adapt them to their testing needs as desired.

SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM 11
Virtualization on your
desktop
Once you have realized the value and importance of
having virtualization solutions, you might begin to
explore the virtualization solutions market to find the
right solution for you.
Traditionally, virtualization solutions have been designed
for heavy enterprise use. In other words, they were inher-
ently developed for big enterprises that had the resources
and manpower to create and develop services on a solu-
tion with multi-tiered architecture. Many of the virtualiza-
tion solutions on the market today echo this legacy aspect.
The solutions are hard to set up, need specialized infra-
structure to get up and running, and require resources and
personnel for administration and management of the tool.

Its easy to create virtual services quickly on your desktop and choose appropriate routing

SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM 12
The problem with these traditional virtualization solutions reuse, customize, and host these virtual services
is that they make it very hard for teams to install and immediately on your local computer. In addition
use it for day to day software development activities, to local creation of virtual services with ServiceV,
especially when software scope changes frequently and SmartBear also enables you to share them over the
teams need to be reactive enough to respond to these network with an offering called VirtServer, which
changes immediately. A solution that requires you to sits on the network or on the cloud to enable easy
contact an administrative team just to edit a virtual service installation and access of virtual services by the team.
every time a scenario changes, will not add much value
as the overhead time associated with the administration
offsets the time savings you will have due to the use of the
virtualization solution. An effective virtualization solution
should not get in the way of your development and testing.

SmartBear provides solutions for quick and easy creation

of virtual services. These virtual services could be created
within seconds on the users desktop and used immediately
for the testing and development purposes. There is no
need for setup and execution of these virtual services over
the network or through an administrator.
Immediately create a virtual service on your desktop for
The primary problem that any tester or developer is trying immediate consumption
to solve on a given day is to complete the development
and testing for that day without hindrance. The ability
to emulate an unavailable resource helps to meet that
need. SmartBear ServiceV Pro enables you to create,

SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM 13
Sharing your virtual
services with the team
Often there is a need for developers and testers to share
the virtual services theyve created with the broader team.
Scenarios where this might be required include:
Business users sharing domain expertise
throughvirtual APIs
Developer sharing virtual web services with testers
Developer sharing virtual API and web services
with consumers
Service designers creating prototypes using
virtual services
When the creator and consumer of a virtual service is
different (and not co-located), a mechanism for sharing the
service is required. The most effective way to share these
virtual services is through hosting them on a network. This
network could be local to the creator and consumer or it
could be remote, with the creator of virtual services in one
corner of the world sharing the virtual service using cloud
services to a consumer in another part of the world.
SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM
Quick and easily install services from desktop onto shared
VirtServers
Sharing of virtual Services should be quick and easy, there
should not be a need for the user to go through a series of
steps just to share a service. Traditional heavyweight service
virtualization solutions have an architecture that forces users
to contact administrators and IT teams to set up their shared
virtual services. On the other hand, an easy to use service
virtualization solution like ServiceV Pro allows you to share
the sophisticated virtual services that you have created with
your team or consumers through a drag and drop of the local
virtual service to VirtServer. The VirtServer on which the virtual
service is shared does not need an administrator. Its so simple
to set up and configure that anybody on the team can do so in
just a few minutes.
14
Automating your virtual
services
We already know that having a virtualization strategy
is important to accelerate your software development
and testing process, because virtualization helps in
reducing the delivery time. Any strategy that you use to
accelerate software delivery also must work well with your
existing processes and frameworks: DevOps, continuous
integration and continuous delivery. These processes, in
turn, depend entirely on automation. Service virtualization
creates sophisticated environments (to emulate
unavailable dependencies) for development and testing.
and its important for the service virtualization solution
to automate too.
Service virtualization solutions should integrate with
automation Frameworks like Jenkins, TFS, and Bamboo
seamlessly, so that before automated testing of an
application begins, the virtualized environment is
automatically spun up, and after the tests have run the
virtualized environments elegantly winds down.
SERVICE VIRTUALIZATION MADE SIMPLE WITH SERVICEV: AN EASY-TO-USE SOLUTION FOR EVERYONE ON THE TEAM
As always, its important to check that the virtualization
solution you are considering does not require you to
manually change configuration or write a script. It should
not require your testers or developers to go through
specialized training just to get started with automation,
neither should it require specialized customer support just
to get started with automation.
ServiceV Pro enables automation of virtual services
through just a few clicks, by copying pre-configured
command line options to the automation tool of your
choice. ServiceV Pro also provides integrated plugins
with Jenkins which enables fast incorporation of virtual
environment in the automation pipeline, making deep
integrations with the Jenkins automation pipeline a breeze.
15
Easy Service Virtualization
with ServiceV Pro

TRY IT FOR FREE TODAY

 The Leader in Software Quality Tools for Teams

6.5M+ 22K+ 194

Users Companies Countries

We create the software tools that development, testing, and operations teams use to deliver the
highest quality and best performing software possible, shipped at seemingly impossible velocities.

With products for API design and documentation, API and UI level testing, code review, and
monitoring across APIs, web, mobile, and desktop applications, we equip every member of your
team with tools to ensure quality at every stage of the software cycle.

See Some Succesful Customers >>

API TESTING PERFORMANCE CODE

R EA DIN E S S MON ITOR I NG C O L L ABO RA T I O N

Functional testing through Functional testing, Synthetic monitoring for API, Peer code and documentation
performance monitoring performance testing and test web, mobile, SaaS, and review
management Infrastructure

SEE API READINESS SEE TESTING SEE MONITORING SEE COLLABORATION

PRODUCTS PRODUCTS PRODUCTS PRODUCTS