Service Virtualization – QA’s best friend

Today’s Guest Blog is written by Dave Flynn, Hewlett-Packard Solutions Architect and HP Service Virtualization Evangelist.

The Problem

About a year ago, I was asked to visit a major bank to show them how to utilize HP’s Service Virtualization solution. This bank needed to make changes to their publicly facing application which calls an external 3rd party credit bureau service. Both the bank and the credit bureau have agreed on how the new service will talk with one another and the WSDL (the contract) file has been provided to the bank by the credit bureau. Both the bank and the credit bureau go off and start digging in to their respective code base and making the relevant changes. The code changes would not affect the web UI but new input data and response values were anticipated to change.  Because of this, the testing team would need to make changes to their HP Unified Functional Test (UFT) scripts to fully validate the bank’s web UI.

This was a challenging situation, since the testing team would need a working system in order to validate their modified scripts. It is a big enough chore to orchestrate environment availability when all you only need to deal with internal systems, but when you must orchestrate with the external systems owned by a 3rd party, the challenge is exponentially more difficult. The testing team didn’t want to wait until the last minute when the credit service had a working system, nor did they want to pull 18 hour days and a weekend or two to get all the work done in time to make the go live date.

The bank started to address this challenge by having the developers write stub code. Though this looked and sounded promising in the beginning, it proved to have many challenges. The stub code was  too constrained in its data responses and the lack of flexibility if the services changed.  The two biggest drawbacks was having to pull developers from other more productive work in order to create what amount to “throw away code”, and that developers needed to have a deep knowledge of networks and protocols in order to create a solution.  One online retailer I worked with said their developers spend as much as 25% of their time in creating stub code.

The Solution

The team turned to HP in search for a solution that would integrate to both HP UFT and HP Application Lifecycle Management (ALM).

The solution was HP’s Service Virtualization (SV), which enabled them to decouple the front end from the back end service provider.  This allowed them to test whenever they needed with both positive and negative test data without having to get the service provider involved. SV has a flexible and easy to use interface which lets the testers focus on modifying their UFT scripts and the data without spending time on creating throw away stub code and learning low level protocol communications. Since the SV used the WSDL to understand what operations are available for a service, the testing team discovered within the first 15 minutes of creating the virtual service that the developers were incorrectly sending SOAP messages.  This defect would only have been discovered late in the development cycle during end to end integration tests.

As the team went through and modified their UFT scripts, they were able to configure the SV virtual service to respond with both positive and negative data in order to validate their scripts would function correctly and supply the good triage information when they executed the tests for real.

In the meantime, with every build the developers delivered, the testing team was able to validate the new build ensuring it didn’t break any existing functionality (aka – continuous testing).  This fast turnaround of code and testing actually put them ahead of schedule which enabled the testing team to perform a complete functional regression test with time to spare before they needed to start the full scale integration test with the credit bureau.

Why Service Virtualization is QA’s Best Friend

In this situation, the QA team:

• Eliminated time waiting on systems for the team to start adding value to the project.
• Found issues early when they were cheap to fix that would have only been discovered during late stage integration testing.
• Were enabled to perform iterative tests during the development cycle to prevent bugs from creeping in.
• Were enabled to perform a complete functional test cycle without being pressed at the very end to try to complete execution of all the tests.
• Instilled confidence with all groups involved: testers, developers and management that they were delivering a quality application.

Probably the best benefit of all is HP’s Service Virtualization is a solution that can be leveraged by both the QA team and the development team to create applications faster with better quality.