Recently, I started learning more about IBM Rational’s integration test and service virtualization offerings — like Rational Test Workbench, Rational Integration Tester, and Rational Test Virtualization Server. Previously, I worked on a solution for Governance of Application Development Outsourcing, which explored how Rational offerings could help companies collaborate more closely with trusted suppliers to increase the success of their outsourcing endeavours. Service virtualization was an aspect of the solution, but not a primary focus.
As I continue to learn more about service virtualization, I’m struck by how our outsourcing scenario provides a great example of how companies can benefit from it. We all know that the later in the cycle that you find a defect, the more expensive it is to fix, and that integrations can be a rich source of defects. Virtualization allows you to start testing earlier, to simulate interactions with other services or applications, and even to simulate a production environment that may not be readily available.
Consider the scenario: JKE, our favourite mythical financial services company, has outsourced development of several applications to trusted partners. They want to enable customers to use their mobile device to locate charities in their vicinity and make a donation. This requires changes both to MobileCharity, which is outsourced to SupplierA, and their back-end Billing system, outsourced to SupplierB. The applications deliver on different schedules. If JKE waits to test the capabilities and integration until both applications are delivered, they risk finding issues late in the game that could delay availability and increase cost. And imagine if they find a defect in one application after that supplier has already moved on to other work – that could impact availability of other releases as well.
Instead, JKE collaborates with both suppliers to define and agree upon the behaviour and interactions between the two applications (and any other systems or services that may be impacted). For example, MobileCharity passes the user name, charity name, and amount to Billing; Billing returns a payment confirmation. JKE integration testers use that information to build one or more virtual services or “stubs” that simulate the behaviour(s) of each application. They can also use the interaction model to write tests to test it, using data from a file, spreadsheet, or even a database.
As they get drops of each application, JKE can continue to execute tests, running the virtual stubs for any capabilities that have not yet been implemented. When SupplierA has implemented the calls to Billing from MobileCharity, JKE testers can begin using the application instead of the stub, while still using the stub for Billing, identifying any integration issues on the MobileCharity side right away. JKE testers may also want to simulate other parts of the environment as well, such as user verification or donation history from the CRM system, where they can’t access the real CRM system.
And that’s not all — consider the suppliers’ perspective. They can also use virtual services for their own testing, to ensure it works before they deliver the driver to JKE. They can also simulate other services that may be running in the JKE environment that the supplier can’t access.
So virtualization could come in handy from unit test right through to pre-production integration/system test. And in an outsourcing situation — where the supplier is even further isolated from the target production environment, and the customer has to integrate deliveries across different release timelines — it could really enable earlier testing and earlier issue detection, avoiding costly delays late in the cycle. Cool.
fryerk (aka Kathryn Fryer) 