Chicken-and-egg quandaries are a big problem in software development and a chief reason that app development is perpetually delayed, flawed and over budget.
Here’s what I mean: How do you design and test a reliable customer web portal for an online store if you don’t have access to warehouse inventory and credit card payment systems? Maybe those two dependent systems don’t yet exist. Maybe those systems aren’t under your control, and getting access will be too expensive.
As we’ve written on this blog, Service Virtualization plays a big role in reducing performance test time from months to days. But as Alan Baptiste suggested in his blog last summer, it’s important to also consider the way a Test Data Manager can work hand-in-hand with Service Virtualization.
Because although SV can provide a form of parallel, on-demand access to components various teams need in development, realistic data is a must, and sometimes you simply can’t get it, for whatever reason. And if no service exists to capture such realistic data — complete with outliers or heavy-demand scenarios — sample data must be created.
With a sophisticated Test Data Manager, you can create a virtual service that covers a full range of possible scenarios without hundreds of man-hours (read: $$$$) spent creating it manually.
As a result, your team can fully test software and find problems sooner and more reliably. Projects get finished faster, cheaper and better.
Test Data Management can take your existing virtual data and augment it with synthetically generated data, or it can create virtual data with a full range of possible scenarios from scratch. That includes structured and unstructured messages and dummy data for future scenarios and prototypes. Your team can test the app-in-development against any eventuality.
Let’s get back to the scenario I raised at the top: Your new online store. What if you had to create it without access to the inventory or credit card service?
Using Test Data Management, you could create dynamic virtual data sets for each constrained element — even if you had 20 instead of two dependencies.
Your new portal can be rigorously tested against the virtual inventory and credit card systems. Relevant data in the virtual order database will be reserved for a “customer order,” and request-response pairs will be generated for that imaginary customer’s “credit card.”
The synchronized reserved data and generated request-response pairs will cover all outcomes — without expensive manual processes.