I can use functional performer automation everywhere. However, the questions still remain of when and how I need to use it.

If I run a load test and I need a Service Virtualization, I can use the same asset. But when I'm using the same asset against the functional test, do I need to use it as is, or do I need to modify the workflow?

They must have that pace, but the product itself is up and coming as a new product in the market. Companies themselves are struggling to find out how they can align the technology with testing and developing practices, or where they can fit it into functional automation of performers or integration.

At the same time, there are a lot of emerging technologies coming onto the market. These other companies are saying that Service Virtualization leads to the first step, and then they realize that protocol leads to the fifth step.

The problem is that there is too much around. I hope that the company who manufactures a product will be more focused on how they can reduce this timeline distance by utilizing Service Virtualization.

If I have an in-house application in place, it allows me to pull information. If I can create an in-house environment manager, then I can go and buy some of the off-the-shelf products from the industry, and then I can do it.

This allows me to have that control of each Service Virtualization asset. It also tells me if somebody has done some sort of ideological testing, or ideological test flow. It will let me know how I can adopt that work flow and add my ideas. Alternatively, I can really go on his idea and tell the developer that the idea sounds great, but it should have been done another way.

So some other benefits I actually think I made the tool do something it wasn’t really meant to do but it worked perfect for my environment. So we had a big project to tokenize credit cards. We wanted to get out of the business of hanging on to credit card numbers because of the inherit risk. So we had a massive project to come in tokenize those credit cards. One problem is the vendor much like any other third party comes back and says, well we don’t have a performance environment for this so… And if you performance test against our environment we’re gonna cut your access off because that’s gonna impact other people. So naturally the team turned to me and said, hey what do we have, can we virtualize this? I reviewed what they were doing and it was not a service call, it was actually a website form post. So I turned the call into rest call, slid it into the config file, told it to point to my service virtualization, and it worked just like an HTML post call and it worked perfectly. We were up and running probably within a day with this virtualized uh, endpoint. I couldn’t believe it ‘cause that’s not what the tool was made for, but it worked perfect. So that was one of those added benefits, undocumented features, right?

I think a big thing for us is a tighter market and a reduction of wastage. We have a number of end points in the environment that are not terribly reliable. If they failed, then we could end up with tens of hundreds of people suddenly not being able to test or validate.

With Service Virtualization, we can replace them with something that is much more stable. We also get view commonality, so rather than developers and test groups creating their own mocks of environments, they'll have one project service with a tool set that does the same thing.

Also, we've got a high level of compliance now with everyone using the same tool. The downside is, if it's wrong, it's wrong for everybody. The upside is that everybody's testing against the same thing so we have a degree of commonality. When all these developers are doing the unit tests, once we get to the multiple test environment, we're unlikely to see a different problems caused by different issues.

Teams have reduced the amount of delayed development effort it takes to roll out a new product by leveraging a virtual service for development and then meeting up for a final integration test when it is complete. The tool has been highly useful for edge case and negative test case efforts by QA as well as useful for high-volume levels of performance testing against third-party endpoints.

• Shift-Left by enabling Build and QA teams to conduct Development Integration/ API / Performance / System Integration Testing
• Remove wait times for constrained services and speed delivery
• Reduce infrastructure costs
• Eliminate expenses from dev/test access to third-party services
• Reduce downtime risk

Everyone needs test environments, dead environments, environments for performance testing, a stage environment, etc. We can build them, but they're expensive. With Service Virtualization, it's much less expensive and we can turn them off and on when we need to.

This product has provided us the capability to virtualize dependent systems, which has resulted in the following improvements to our organization:

• More productivity
• No dependency on third-party systems
• Faster test execution cycles

It has improve our organization a lot. For example, one of our very recent client's implementations that our Patson USA team did, we saved more than $15 million. This is in confirmed savings. In the past three and a half years of our implementation there, it helps you avoid the environment, get your software to production a lot faster, and reduces the wait times. That means it improves the productivity of your pre-production community. It also helps you in finding defects earlier if you can shift your testing left and integrate your application under test with virtual services.

With this solution, you don't have to use your production services for implementing other software uses. It saves us time, effort, manpower, and cost, in particular.

Performance testing and infrastructure costs were reduced because of virtual services.

Dependency on other teams was reduced, where we are expecting live services from them and they are not available. We can create virtual services in a few minutes with a few clicks using mocked data. This is awesome.

The concept's almost identical on that topic with respect to the old methodologies or legacy practices. You go in and actually install bare metal machines, put a virtualization engine on top of it, and try to do a P2V move. Where today with the new infrastructure, with basically the new HPE 380 or the similar models of HPE solutions, we're able to virtualize a customer's environments in minutes, not hours and days. That's been able to reduce our services cost and improve our customer retention, as well as the customer end-user experience. We've been able to take their environment and bring it online, and then virtualize the environment very fast.

The solution saved quite a bit of the cost of the hardware. The cost has really gone down.

• It helps my developers share services and access them, and eliminates the need to create and maintain stubs
• It reduces redundant work (doing the same work twice only for testing).
• My developer team is more agile right now.