So a functional tester walks into a bar and the bartender (who is also the project manager) says “why the long wait?”
Does this sound familiar? Over the past several years, application teams have adopted strategies to deliver software solutions faster. They have to meet accelerating business needs and an ever impatient mobile consumer. In an attempt to satisfy this un-ending hunger, we’ve adopted multiple strategies including:
- Service Oriented Architecture—let’s chop up applications into shareable components that we rapidly assemble to support business services and processes.
- Agile methodology—let’s build software quickly in small increments so that we can constantly deliver what the business wants and stay flexible as they constantly change their minds.
- Cloud sourcing—to focus our dev and test resources on what’s most important to our business (our core) and “buy” the rest from the cloud service market (our context).
- Application transformation—to support mobile consumption because consumers want innovative applications and access from their friendly, always on mobile phones and tablets.
It’s all about speed
What if you had the ability to rapidly assemble new applications from available components, deliver capability in small doses via sprints, expose new features continuously to the mobile user and allow users to leverage the cloud with the swipe of a credit card to augment functionality? Sounds amazing right? … But as we rapidly assemble, source, re-use and mobilize, how do we know it’s all going to keep working?
Pity the poor tester who has to navigate the ever increasing moving parts in shorter release cycles. How can we bring it all together at a single point in time to test and validate? It’s harder than herding cats; or in the spirit of the holidays, herding a gaggle of extended family members to arrive to a holiday dinner at 4 p.m.
Let me explain further…imagine our tester who has the objective of testing an end-to-end e-commerce business process. This process is further complicated because an Agile sprint has defined that we must enhance an e-commerce shopping cart service to offer timely promotions to address an expected surge in demand from the holiday season. This end-to-end e-commerce application has a mobile and web front-end, a customer look-up service that calls a database on a mainframe, a java application for the shopping cart and a shipping service that calls out to Fed-Ex in the cloud. The sprint is a two week window…can this be done?
Family holidays and composite applications—the similarities abound
Have you ever had to get 20 family members to Grandmother’s house on time for turkey? Imagine they are flying or driving from all ends of the country. To throw more wrenches into the situation we will add delayed flights, hungry infants, picky teenagers, and a sibling with a strong need for a cigarette break. At this point you know what I’m talking about. Your family members are not all ready at the same time and some are not available at all. It’s the same with composite applications.
Back to the tester—when the developers check the code changes into the build system, the tester needs to ensure that the composite e-commerce application with said shopping cart works end-to-end. But, what if the customer look-up requires access to the mainframe in production? Imagine IT operations say “No way, wait until three days from now in the middle of the night.” What about testing against the FedEx service? Will the service provider allow it, or will they charge the testing team for access or even decline the request?
Up until now, a testing team had three options for the tester:
- Wait – and there goes the Agile schedule
- Don’t test the complete end-to-end transaction... skip the part about the customer look-up or the shipping service access and hope it all works
- Find expensive programmers who speak mainframe, web-services, REST, COBOL, MQ, or some other integration protocol or message format required in the application to write a stub… then find the same expensive programmer for the next Agile sprint when something changes.
However, there is now a forth option—Virtualize the services that are not available and provide a mixed live and virtual service environment for the tester. Service Virtualization is expressly designed for this challenge. With the newly enhanced HP Service Virtualization 2.3, the team can create a virtual version of the customer lookup service and the FedEX service. SV 2.3 makes the virtual versions available for anytime access in the dev-test lab. The tester can author, script and automate tests that represent the end-to-end application flow and leverage the virtual service when the live services are not available. The testing team can continue to leverage these virtual services continuously (for regression testing and continuous integration scenarios).
HP Service Virtualization not only virtualizes SOA-style, REST and Web services but also data services (such as Java services that access data via JDBC) and it can data drive testing scenarios against the virtual service. These are new features of HP Service Virtualization 2.3 that add even more tools to the tester’s workbench for testing composite applications and cloud services in Agile-time.
With HP Service Virtualization and it’s integration with HP testing tools, testing teams can work with the development and architecture teams to identify and rapidly create virtual services from a single point in time access to the target application component to record and simulate, or even from learning and simulating from data structures and self-describing architecture documents (such as IDLs).
Once created, these virtual services are easy to integrate and use in a testing scenarios; either for functional testing (such as with automated integration tests executed by HP Unified Functional Testing or load tests where the virtual service is accessed by many virtual users in HP LoadRunner or HP Performance Center to test load under different consumption conditions). The virtual services can be configured as part of the dev/test lab and made available for access by multiple teams at any point in the project. They can even be part of the overall set of components tested in a regression test triggered by a Continuous Integration process.
Want to learn more about how Service Virtualization can be a tester’s best friend in keeping all the moving parts available to test early and often? Check out the latest information on www.hp.com/go/sv.
And now, if we could only virtualize those chronically late, impulsive family members!