Service virtualisation is a trending topic for service-based enterprise architectures. If you believe the hype... virtually, anything is possible
Some time ago, my colleague mentioned an interesting article about service testing and service virtualisation from a unique standpoint… Formula 1 motor racing.
When you think about some of the challenges that testing faces in a modern application development world, you could make an analogy with F1 racing. Not necessarily a common association, but a starting point nonetheless. When I think about F1, I automatically think “Ferrari”. Why?
F1 is an industry, an industry dominated by technology and cutting edge innovation. Ferrari used to dominate F1, positioned regularly on top of the podium. We think about the world-class drivers, sponsorship deals, money and, right at the heart of it, the business. In terms of governance, we think of the FIA (Federation Internationale de l’Automobile).
Now apply this analogy to traditional testing teams. A test analyst might ask for:
- A copy of every race track in the competition
- The ability to test changes to the car on every track
- Testing only when the part is in the car on a specific track
- An experienced F1 driver for testing of multiple track alterations and conditions
F1 has become a cut-throat industry. Once upon a time, if you were the fastest at the beginning of the season, you would be the fastest at the end. Back in the glory days of Ferrari, this was very much the case. But no more. Change is constant, teams are rolling out business-driven improvements on a race-by-race basis, technology is evolving at a great pace and your team has to follow suit or get left at the start line.
The same challenges apply for today’s testing teams. At Assurity, we see a growing demand for QA solutions to address time to market. While the development world is embracing Agile methods, the current generation of QA tools struggle to keep pace.
Our clients don’t have the time to test everything together – a demand that brings a shift in testing practices. Just as F1 cars are designed to be closer to the track for better traction and control, we need to test closer to the application code and below the presentation layer.
Service testing allows for this where integrated teams of testers work with XML, Schema and WSDL validation, web services and related communication standards all within a complex integrated architecture stack.
In such an environment, not all system components are integrated end-to-end on day one. Incorporating a virtualised service environment is therefore a must if in order to communicate with the grand old mainframe processing engine over an adaptor, or call a secure downstream rules verification engine so that testing can commence and add value when components are available to test.
Let’s come back to a single challenge to test environments – the test tracks of the application development world. Ferrari would have once:
- Had their own test track on demand
- Transported a car to an unused track and tested it when necessary
- Used data from other tracks, a simple test track being enough due to the limited complexity of cars
But this is no longer the case thanks to complexity, money, legislative change and a marketplace competing for glory at any price. To some extent, this is also true of application development. Companies which worked in this limited testing world, no matter how well-tooled and financed they are, are struggling to be relevant in a new test world characterised by so many moving parts.
“According to recent research by industry sources and the National Institute of Standards and technology (NIST), software testing represents more than 50 percent of overall development costs, and testing teams often spend upwards of 30 percent of their time managing the complexity of the test environment.”
source: IBM & NIST
On a basic level, we should know the impacts of our changes within an SOA, B2B or composite application domain. But whether we choose to is a different story. We should know what we can simulate realistic to the system under test. An F1 technical mechanic can tune a car’s on-board computer systems from a laptop… but only the driver knows the true results.
Apply this to software. It’s the tester who should own and configure our virtualised services and create realistic scenarios for mocked services to test against.
So service virtualisation offers numerous benefits. By standing up and operating one or many Virtual Integrated Environments, one can test better, sooner and more completely while also saving on time and cost.
At Assurity, we see clients at various levels of maturity adopting such concepts and investing in service virtualisation – either to mock internal services and core components, communicate with an external vendor via a B2B channel or in the cloud. The project and the time to market demand it.
As a result, testing takes place earlier and key business stakeholders have a vision of how end to end core components will communicate and deliver key business process outcomes once completed. That is an incredibly powerful message to deliver in a highly complex service-based architecture early in the project.
A note of caution however. Simulation is still simulation. No matter how good, it is never enough to test only with simulators especially when applied to a specialist area such as performance testing.
We’ve have seen how our clients can benefit and we believe that as an organisation's SOA maturity evolves, the demand and growth in service virtualisation will align as key considerations. Applied correctly with a test strategy and test tool framework that are closely governed, virtually anything is possible!