How to use stateful virtualization to trick product managers into focusing on what’s important

When it comes to end users, they don’t care about the back-end madness taking place on your site. A user’s main concern is getting done whatever it is that they came to get done on the web page, no matter what sequence of steps it takes to get there. A virtual service that can simulate this behavior will allow for earlier end-to-end testing, improved coverage of all the business logic requirements, and effective product demos to product managers.

In one of our less glamorous sprint reviews, one of the product managers showed frustration with our team’s demo, as we could only show the newly-implemented features/services individually and not the end-to-end workflow. The reasoning for this was simply because not enough functionality had been implemented yet to link the data across the different services. For that particular user story, the product manager didn’t care to see the individual pieces of the puzzle, he wanted to see the pieces put together as a whole: the business logic.

So, this being a company that makes software testing tools, we used one of them to give our product manager what he wanted. And since then, we’ve leveraged service virtualization (Don’t know what that is? Read more about about service virtualization here.) in a lot of our demos and in our overall workflow. Service virtualization enables us to use virtual services to represent unavailable services that are still in development by other teams working in different sprint cadences. It allows us to stand up “intelligent stubs” that exhibit realistic dependency behavior or completely fictitious behavior to suit our needs. By simulating the portions of our demos that are unavailable, we can give product management demos that show entire workflows to get the feedback we need, without getting hung up on the pieces that are out of scope.

Service Virtualization with the Data Repository CRUD Tool

Virtualizing individual service calls is easy enough, but ensuring those individual calls behave accordingly as part of a whole system is something else. The subject becomes more interesting when some of those services require persistent data to be maintained between calls. When persistent data is involved, it is essential for the virtual service to manage the data across the different states and truly simulate the behavior of the real service to more accurately represent the business logic behind the application. We call this “stateful virtualization” and you can read all about it on our blog about adding life to service virtualization with stateful and state transition testing. Here is where the Data Repository CRUD tool comes in.

Parasoft Virtualize (our service virtualization solution) has a feature called the Data Repository CRUD tool. The Data Repository CRUD (create, read, update, delete) tool was created to handle the data persistence problem that is often associated with web services that require state transition.

Consider the traditional shopping cart experience. Let’s say a shopping cart system is made up of 3 web services: the inventory service, the cart service, and the payment service. Each of these services have their own data set, but their records share an element or attribute (inventory ID, cart ID, transaction ID) that needs to be honored to proceed to the downstream service. In addition to the shared element, the record of items in the cart, their amount, and the total calculated price needs to be maintained throughout the shopping experience to fulfil the checkout process.

A minimal solution would be to virtualize a fixed scenario where a user searches for a static item, adds the item to the cart, and finally completes the checkout. However, we know online shopping can be more complex. When the real service is swapped with the virtual service, the behavior should be seamless and transparent to all the other services interacting with it. Therefore, we can’t assume this will be the only scenario that gets run against the virtual service.

A user may decide to add a different item, update the original item, or remove it all together in a sudden act of discontent or shopping fatigue. Human behavior is unpredictable. The Data Repository CRUD tool allows us to simulate this unpredictability by creating and modifying records on the fly and maintaining it between user actions. This allows us to fulfil any sequence of events that is thrown at the virtual service with ease. Any arithmetic or additional logic will be handled by the tool effortlessly.

Aside from our sprint demos, I had the privilege of assisting in two separate projects this year where the capabilities of the Data Repository CRUD tool proved incredibly valuable. Let me walk you through them.

Stabilizing dynamic environment data during performance testing

A performance test was required for an application that integrated with several third-party services. The development team already had one or two static records that they used to validate that the application behaved as expected throughout the course of their test. However, for the performance test to be valid, the data and the actions performed in the test would need to be random with high variability, to properly simulate a real-world scenario. The state of individual data sets needed to be consistent between all individual services, including the third-party ones. It would have been simple enough for the development team to inject new database records into each dependent third-party service, but unfortunately, access to the sandbox environments came with a high cost and a plethora of potential headaches.

The team was able to successfully implement their performance test using service virtualization and the Data Repository CRUD tool. Any record that didn’t exist in the virtualized service during runtime would be created in its initial state by the tool in a “catch all” configuration. The virtual service would then use the newly created record to successfully respond back to the request, and modify it over the lifespan of the test. The set-up was surprisingly painless, and guaranteed a real and reliable end-to-end flow for each unique user generated by performance testing tool.

Injecting real time data into a system under test

The second case was unusual, but certainly fun to virtualize. The case involved testing an application that worked with a state-run vehicle registration system. Whenever a new VIN (vehicle identification number) was added to the application, it would send asynchronous calls to the registration system to request the vehicle’s complete information. If the VIN didn’t exist in the system, it would respond back as unregistered. Unfortunately, the registration system had a mandatory policy that required the new vehicle information to be manually inserted by a person (yes, a living, breathing person). The system would respond differently if the information for the requested VIN wasn’t registered after a certain number of requests.

This general behavior is common for asynchronous services. This is essentially the equivalent of a child asking “are we there yet?” during a road trip — a question one would typically ignore unless they are actually getting close.

Once the person manually registered the information, the system would respond with the confirmation payload. The goal here was to simulate the vehicle registration system to test the application independently. The challenge was determining how to configure the virtual service to respond differently to an identical request at different times. To accomplish this, we used the Data Repository CRUD tool to keep count of the number of calls made with the same request. After a particular count number was reached, the CRUD tool would update the state of the record for the virtual asset to respond differently. The CRUD tool was also configured to create a new record for any requested VIN randomly within an expected time window to simulate the manual registration process. Something that initially appeared difficult was easily accomplished with the right tool.

Summary

The truth is that when it comes to an end user or a product manager, the back-end madness that takes place during a simple web page action is negligible. A user’s main concern is that whatever they came to get done on the web page will get done successfully no matter what sequence of steps it takes to get there. A virtual service that can simulate this behavior will allow for earlier end-to-end testing, improved coverage of all the business logic requirements, and effective product demos. With recent enhancements to Parasoft Virtualize‘s CRUD tool UI and configuration design, it is now so much easier to handle complex scenarios and provide the real world functionality that your stakeholders, product managers, and testers are looking for, as early as possible.