SERVICE VIRTUALIZATION

SERVICE VIRTUALIZATION

 Service virtualization is the process of creating replicas of systems that new applications depend on, in order
to to test how well the application and systems integrate. It is primarily used for  integrating applications that
depend on cloud and service-oriented architectures (SOA), or applications that communicate with third-party
data and application program interface (APIs.) Examples of these systems include customer relationship
management (CRM) services such as Salesforce Service Cloud, enterprise resource planning (ERP) services
such as SAP ECC, and internal systems that are still in development.
Developers can implement a virtualized replica of the dependent system so integration testers can see how
well their application integrates. This allows development teams to save money and time by testing
throughout the development process. Otherwise, they would need to wait to test integration until these
dependent systems are available, which might take a long time because a third party controls them or they
are still in development.
Unlike server virtualization, service virtualization only replicates specific interfaces, interactions and
behaviors -- situations wherein a server might interact with an application -- rather than a complete server.
HOW DOES SERVICE VIRTUALIZATION WORK?

 Service virtualization tools monitor traffic between the dependent system and the application. They use log
data to build a model that can replicate the dependent system's responses and behavior, using inputs such
as SQL statements for databases and Extensible Markup Language (XML) messages for web services. As
developers test the new application, the virtualized service produces the same responses that the real one
would.
 Developers use this simulation to test how a new application, service or feature integrates with existing
infrastructure. Service virtualization removes a significant development bottleneck by ensuring testers don't
have to wait to begin testing. This allows teams to release products with fewer defects, on time without
disrupting service.
 Testers can also build in special cases that simulate high traffic volume or slow connections. Once the
application is ready for integration, developers can replace the simulation with the real thing.
SERVICE VIRTUALIZATION VENDORS AND PRODUCTS

 Parasoft developed one of the first products with service virtualization functionalities in 2003, but iTKO
invented the term in 2007. Major players have since developed or acquired their own service virtualization
tools; IBM acquired Greenhat, CA Technologies acquired iTKO and Hewlett Packard Enterprises developed its
own technology. Other companies that offer service virtualization tools include Hoverfly, MockLab, Traffic
Parrot, WireMock and SmartBear.
BENEFITS OF SERVICE VIRTUALIZATION

 Service virtualization benefits are most acute in rapid deployment and continuous delivery scenarios. It allows
teams to rapidly iterate on test results throughout the development process, which can be a boon to DevOps
 and Agile teams. Service virtualization helps these teams prevent bugs during development, build better
systems with fewer defects and share responsibility for testing the quality of the product across departments
 Benefits of service virtualization extend to companies outside of these rapid workflows, too. For example, if an
organization wants to upgrade its back-end systems, it might risk downtime-causing integration problems once those
systems come back online. With service virtualization, developers can test the back end as they improve it, and test
its interactions with the front end before full integration.
 Service virtualization allows developers to keep up with application development even when there are missing
components. Before service virtualization, testers needed to wait for applications that were nearly complete. Different
teams with different schedules, priorities and requirements would often need to finish and assemble the application
before the testers could access it.
 The rapid, integrated testing that service virtualization enables helps development teams meet their deadlines and
ultimately get the product on the market faster. Testers can catch a potentially disruptive problem earlier, which helps
development plans remain on schedule. Service virtualization also allows organizations to avoid setting up expensive
testing labs.
DISADVANTAGES OF SERVICE VIRTUALIZATION

 Disadvantages of service virtualization involve cost and implementation. Budgeting for service virtualization
implementation can be difficult because its usage crosses many different departments. It can be difficult to
assess who has ownership over testing and who should be in charge of service virtualization.
 Additionally, service virtualization doesn't replace full integration testing with the actual dependent systems.
Service virtualization enables integration testing throughout the development process, which speeds the final
testing, but a final test process is still necessary.
SERVICE VIRTUALIZATION VS. MOCKING AND STUBBING

 Mocking and stubbing are similar to service virtualization, but they function on smaller scales. Mocking and
stubbing usually involve testing specific behaviors in restricted contexts, whereas service virtualization
replicates systems at a production scale.
 The growing popularity of service-oriented architecture and Agile development exposes limitations to mocking
and stubbing. Service virtualization approaches testing at the infrastructure level and creates models that
different teams can reuse in different circumstances. Mocks and stubs typically require manual development
for each use case. Service architectures typically require too many dependent variables for mocking and
stubbing to be practical, and agile workflows demand a speed that these methods struggle to meet.
 Beyond that, developers are more likely to introduce errors into stubs and mocks based on their assumptions
of how the application is supposed to react in each situation. Quality assurance teams can integrate both
technologies if they use service virtualization when they need to emulate systems and mocking or stubbing
when they only need simple, context-specific unit testing.
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 don’t have strong coding skills, they’ll find this very hard to
do. There are not many ‘easy to use’ open-source tools available for mocking.
 A good example of a 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 doesn’t make it easy for testers to scale and adapt mocks to multiple testing scenarios.
 It’s 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, you’ll find it hard for you to configure it for all these permutations.
REASONS WHY MOCKING IS NOT SCALABLE

 1. Mocking does not support quick creation of scenarios for testing at a moment’s notice.

 Mocking can be very ‘personal’, as it’s hard for developers or testers who have spent a lot of time creating these mocks to share their work with their
peers.
 2. Mocking is stateless.

 This means that it’s 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, it’s 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.
 3. Mocking 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.
 4. Most of the testers and developers working with APIs spend most of their time working on the
front end.
 Therefore, their knowledge of API technology and specifications is limited. A modern-day API is built 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 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.
  
YOU NEED 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 Google 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.
 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 card’s 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)
  

 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.
 It’s 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.
 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, it’s 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 MySQL 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.
 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 enable teams to move faster, work continuously, and deliver 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 environments and they can quickly customize these environments and
adapt them to their testing needs as desired.