Broadcom Service Virtualization Reviews

To give you an example, we have had developers produce code later than we wanted to, but we've had some other stuff that was dependent on that. So what we were able to do was virtualize these assets and then go forward with our developer and not have to wait for these additional services to be available.

We have been using it extensively for the shift left process and testing. It helps us to accelerate and virtualize services and assets that we don't have. It enables to test faster.

From a reporting perspective I think we would like to have a more user-friendly approach. I think that's primarily where we would like to see some improvement. Otherwise we are pretty happy with what we have.

It has been very stable for us. We have been pretty happy with its use.

We are able to quickly scale our requests. We have tested across thousands of requests. We have had no problems so far.

Technical support has been excellent for this product. CA has always been available for us when we had questions and they have helped resolve any issues that we have had quickly, and in a very efficient manner.

We didn't have a solution beforehand. Essentially, we had to wait for developers to give us the code. What this helped us to do is get over that bottleneck and not wait for assets to be available. We were able to quickly go out and have the testing or automation team build out a solution beforehand, based on the contract, and then go forward.

I would rate it pretty highly. It would be close to 10 out of 10 for how it helped solve our needs.

It allows you to have a bunch of manual testers who can easily use the tool set, as well as hardcore devs or SDETs who know how to code. They can also use the tool set.

And, on the virtualization side, it really kind of helps you save money, because you can unblock yourself. If something's not ready, you can go and virtualize that, unblock your automation. We actually found in the last project that we should have used more virtualization, because our environment wasn't really stable. And so, we should have virtualized the things that we were automating so that we could demonstrate the automation wasn't the problem. That was always a question mark for people, and so that's a takeaway that I'll do again on the next project.

A couple of the most valuable features, to me, are the fact that you can have a lot of different people with different technologies use the tool, without any programming experience at all, all the way up to people who can program. And then, the more technical that you are, the more programming you have, the more you're able to customize the tool. Basically customize it to do what you want it to do. That's one thing. 

The other thing is, it's got probably the greatest amount of features, in terms of different technologies that you can automate and virtualize, out of any of the solutions out there. So, it really can accomplish any task that you want to do with it.

I really want to see more of the "express" kind of model, where you get a little bit for free. I'd love to be able to see you be able to edit and author tests without having to be connected to a licensed server. And then, if you want to go and execute tests, then you go and connect to the server. That's a request I've been making, and I'd like to see that. I think it's in line with the open source model, and I think it would unblock people to be able to do a lot more work from home or from remote places, where they can't really connect to the server.

It's very stable. It's very robust. 

I have noticed that sometimes memory consumption can get high if you use the tool repeatedly. But, it's pretty manageable. It's come a long way. I've used it for multiple versions, and I'm on version 10 now, and I'm very happy with the stability. 

It's very scalable. The server, we've actually scaled it up quite a bit. One of the projects I was on, we were running thousands of tests, and the server wasn't really set up to handle that. So, we increased the amount of coordinators, and RAM, and processing power. And, just by making those small changes, we were easily able to scale to, like, thousands and thousands of tests. I'm happy with the scalability.

I wasn't using any previous solution. When I came to T-Mobile, SV was a fairly new tool at T-Mobile. So, we didn't have any other previous solution. We used this one, and none of the other solutions that have been out there have been better, so we've kept using it. Didn't need to switch, and we have been continuing to invest in it, because it's been meeting and exceeding our needs.

I give it between an eight and a nine out of 10. I don't ever really give 10s, because I always think that things can be improved, so it's a great product.

We use it for service virtualization. It is performing well. 

Unit testing or early life testing did not have to be stopped or delayed because those services were not available. So, they can continue testing using this capability, whether those services are available or not.

It performs as advertised. We had a number of back-end services that were not available during testing times. What this had allowed us to do is get our early life testing done while those services are not available. 

We had to implement an external service catalog. We put it in ServiceNow. I would like to see an integrated service catalog. 

What we have done is put redundant systems in, so it is stable. We are on-premise, so we are not using the cloud version of Service Virtualization. 

It is as available as we can make it in our E2 environments.

It does scale up.

We had some on-premise support when we first implemented it, and they were excellent. We had some training for the product when we first implemented and that was excellent. We could not have been as successful, I don't believe without it either, because we had very complex environments early on in our DevOps journey. This was the first thing we were trying to automate back in 2011, so if we had it to do over again, we probably would not have done Service Virtualization first. However, with the implementation help and the training, we ultimately were successful.

We bought Service Virtualization because we are in a DevOps journey. If you are in need of services that are not available, you need to have a solution. 

I was the product manager that rolled it out to our enterprise. It was very complex.

CA was learning the product at the same time we were learning the product. CA had just bought the product from ITKO LISA (or acquired ITKO LISA). At the time, it did not have enterprise characteristics, since then CA has been able to bring to a large company as far as management capability, security, and things of that nature. When we were implementing it, it did not have that, but it does now. 

Upgrades are straightforward from a CA perspective. They are complex from our company perspective, and that is mostly self-inflicted. 

We did do a bake-off. We looked at three tools and CA was the best. Therefore, CA/ITKO was the choice.

You have to go check this tool out.

The innovation is amazing. CA has continued to add to services that it supports, the transports that it supports, and has built all of the enterprise capabilities into the product as well.

Most important criteria when a selecting a vendor: service and support. Pricing is right up there, too.

It helps us to remove barriers that we have with dependencies on services that we don't own, or services that don't even exist yet, or services that are junky. It helps us to shift left and do our development earlier without waiting on those dependencies to be available.

I work in a test environment so teams come in and they do performance testing on their solutions. Whenever we can get their solution to work with DevTest it makes everything super quick. It reduces setup time, all the engineering you have to go through, and reduces it by days.

You can create virtual services from a live recording or you can even take raw traffic and convert that into request/response pairs, and you can create an entire virtual service from just those simple little files, and that's super awesome when that all works out.

I think the size of DevTest is pretty massive. It's hard to tell what different parts of it can be used to do different things. It gets kind of big, so if they could modulize it more, and lead you to a common work flow, that would be pretty awesome.

They're constantly making improvements, so it's gotten better every time they have released a new version.

It's very stable. It's very reliable.

We spread it out across, I think, 12 different teams using it right now, and no problems.

I have used tech support. They're awesome. They usually get back within minutes if you have a problem and they can get you up and running really quickly.

I was surprised, because usually customer service is not that prompt. But I've used it probably seven times, and every time has been an easy, quick experience. 

There's definitely a learning curve, but they're there with you on site, helping you get set up. At least in our case they were with us, so that removed a lot of the problems.

I give it an eight out of 10, because nothing is ever perfect, and there's definitely a learning curve to it. But if you put some time into it, it definitely helps you out. 

It is throughout the STLC, so we actually have rights from the PoC or idealization from testing, development, and even production support where someone would like to use it for certification, or a sandbox perspective.

It is easy to use, has a faster time to market, and provides flexibility. 

On our customer side, we have actually done a lot with this particular tool. It has helped a lot of teams to accelerate their testing and development, and saved a lot of money on the infrastructure side, setting up the sandbox side, etc.

• Flexibility
• Ease of use
• How much easier or faster we can actually make something happen.

1. The enterprise catalog. Usually what happens is once you have a set of virtual services, then you go to an enterprise. So, people would like to see what is already virtualized and how can they take advantage of it. Right now, it is actually not part of the product, therefore we created something, a custom solution, for it at this point of time. These are two separate things. Sometimes, we have to put some effort into it. If it could be part of the product itself, a service catalog where a user could actually come and see what is already virtualized, how they could actually utilize it, and the value it adds.
2. The access control to the new portal. There is a new portal available and we are making it as a self-service thing. Whoever wants to create their own virtual service so they can actually go there and create the virtual service. The problem we have right now is how do we restrict access to each of those virtual services or the projects. So, that is not implemented in the product yet.
3. Cloud readiness. I know it is available in AWS, but we would like to see how we can actually make it more cloud-friendly.

It is much better now with the newer version. We have had issues when they moved it to a newer platform of a base platform a couple of releases back. So, we had issues in the past, but I would say of the latest version, 10.1, that we are using, it is in a much better position. But there are still areas to improve and we are actually working with CA to give feedback, and they are continuously trying to improve the product.

It is scalable. We actually use it for both functional and performance purposes. In the functional area, it actually works pretty well. In the performance area, we do not know where the limit is at this point of time. So far, it has actually worked well and we are able to bring it to multiple environments. Therefore, I would say it is pretty scalable at this point of time.

They are very prompt and very easy to work with. I have been working on this product for the last six or seven years, so I know most of the support team. It is pretty easy to work with, explain things to them, and get the right support. Also, I am able to get additional details about new feature releases, so it is actually pretty good.

The initial setup was straightforward. We did have some problems with the one of the upgrades. CA actually releases a new version every year, so we try to catch up with it. We have had issues with the prior to last upgrade. This one was okay, the latest one.

We actually did PoCs with other tools, then came up with the pros and cons. This was the product that checked the most boxes.

It does what it promises. I would definitely recommend to take a look at this solution, because of the ease of it.

We are into performance engineering. There are a lot of back-end systems that are sometimes unavailable, or there are a lot of various dependencies, and we're trying to get rid of those. That's one of the reasons we got into DevTest. 

And it's been helping us quite a bit now. We've been able to step out a lot of back-end systems. It's performed pretty well. There were a few hiccups, but we got in touch with the senior architects and they helped us out with fine tuning and, since then, it's been working out well.

The most valuable feature is that it supports so many protocols. We, being a large bank, have almost all the protocols, and it supports all of them, so that's one good thing.

I think it definitely helps us reduce time to market, and in terms of dollar savings it helps us quite a bit. There are many testing applications that reach out to third-party vendors where every transaction costs, and we are able to virtualize all of that and reduce the financial aspect.

One major feature I would like to see is on the user administration part. Right now, anybody can access any of the folders and any of the projects. If they could bring in someone amount of user administration, that would help us a lot.

Stability so far has been good. There have been no issues. There was a learning curve, about a year or so. It took us some time. It's not a plug and play tool. There was a lot of customization that had to be done, but with all of that done I think it is quite stable now.

The hiccups we experienced were mostly to do with scalability.

There are multiple protocols that we actually work on, like HTTP, HTTPS and then MQ and TCP. HTTP and HTTPS were fairly basic, and we were able to get things done pretty efficiently. When it came to MQ and TCP, we came across a lot of challenges. That's when we got CA engaged and they helped us fine tune the tool itself so that we could reach the scale that we wanted to.

I would say they're a four out of five. A lot of times what happens is, they come back with scripted answers and then we reach out to the account manager or somebody. Then they look into it and they help us out. That's why I'm taking out one star for them. Otherwise, they've always been good.

We were on the lookout for a service virtualization tool. 

I would say it was complex.

The initial set up, if you look at the basic functions, it's quite straightforward. But for the scale that we were planning to implement it at, we did not get a lot of support from CA. So a lot of it had to be done in-house. We had to bring in our own architects and do a lot of environment setup and the like. We did not get a lot of support from CA. That's one area where I would say CA could have helped out better.

We did look at a couple of tools in the market. We did a PoC on DevTest. Back then it was called Lisa. Everything went well, so that's how we ended up getting into DevTest.

We didn't do a POC on the IBM product, I think it's called Green Hat - IBM's has a service virtualization tool - and we were actually contemplating that tool as well.

We went with CA because the PoC went well. There were a couple of guys who came in and actually helped us out with all the use case scenarios that we had, and we were able to implement it successfully. That was one of the reasons we went ahead with CA.

When selecting a vendor, our criteria, what we are looking for are 

• easy to use tools
• a good feature set
• and then awesome support.

I would say it's an eight out of 10. Eight because it has so much going on and there's a lot to learn, and there are a lot of things you can do with the tool. It requires quite a lot of learning effort. It's not plug and play. And a lot of customization has to go into it.

I would advise going with DevTest, definitely. It would depend on what you are looking to get out of the tool. If it's some of the basic protocols like HTTP, HTTPS, you could actually do it yourself. But if you're looking at a much larger scale, then definitely DevTest is the right tool to go ahead with.

Easy to understand ways of creating stubs.

Different execution methods of virtual services. Its easy implementation is really helpful when changing the behavior of virtual services.

More examples of portal-based virtualization.

One year.

No.

No.

No.

10 out of 10.

10 out of 10.

No.

Simple and straightforward. Anyone with basic knowledge can do it.

CA technical support and DevTest community people love to respond and come up with a number of suggestions, which is really appreciated.

CA Service Virtualization has helped us advance the development cycle when third-party interfaces are not available to us. We're able to simulate that activity. Working with the developers, we're able to get our testing site done in advance, so that when the integration starts, we're able to get further down the testing path with our third-party vendors.

We are able to get further testing on a couple of interfaces. We do a lot of third-party request out for a loan; fraud verification; credit bureau. A lot of times, those data setup and data needs take a longer period of time than what maybe we have, so we're able to virtualize both the credit bureaus and some of our fraud facilities to get the testing done.

Also, facilitating in the training environments, where training environments are typically used part time, you don't want necessarily to have all the hardware and software laying around part-time. We're able to virtualize those interfaces.

I'd like to see more of the newer technologies included in there, looking mainly from a mobile perspective, possibly, so you can virtualize some of the aspects that we're going to be doing for mobile testing.

As far as the stability, I've used CA Service Virtualization now for eight years, so it's been pretty stable.

It's able to scale. It's easy to scale CA Service Virtualization because of the way the services can be placed onto a platform. You could have a couple of services running on one server and if you have a high demand, you could put them on another server. You're able to have many services running across the organization. They don't have to be co-located.

I've not used technical support. The ladies and gentlemen who work for me are able to stand up the situation. We did do an engagement with CA and we brought them in probably for about three months in early 2016 to help with some of the more complex virtualizations.

We didn't have a previous solution. I've been with the company about 18 months and came in the early part of 2015. We're fortunate enough to get in with our General Motors ELA and I got the licenses for us to be able to start doing the CA SV setup for 2016.

I wouldn't say initial setup is straightforward. You have to have a little background, engineering knowledge, about how it operates. I know my team accomplished it working with CA in relatively short order.

For the service virtualization, especially, a lot of times, we are asked to stand up environments and those will take time; you have to purchase hardware and software. I think if they start looking to CA SV as a solution, we can stand it up rapidly and usually solve the situation in a short order of time, saving both green dollars and hours of setup, for the particular hardware database, whatever you're trying to setup.

My rating reflects the flexibility that it gives, the easy deployment and the easy maintenance of it. It is probably one of the better tools on the market for virtualization. I've seen several.