OpenText LoadRunner Cloud Reviews

It's the license and structure because it's so dynamic. Virtual user hours is much more dynamic than virtual user days, and even more dynamic than static licenses. I did a test a short time ago where we could keep the test to half an hour so we could really optimize this virtual user hour. That was wonderful.

It's used to improve our customers, but we don't use it in-house.

I'm a consultant and this was used for a small project. My customer bought around five consulting days from me. We ran into some undocumented limits around the number of concurrent users. It was really just set up to keep the guys out that wanted to do denial of service using the demo account. It was not clear that this was the limit it would hit. That's expensive for a company. Out of five days, maybe half a day. That's 20% of the budget went into trying to run a test. The test fails, contact support, ask what's going on. Make them move the limit and then re-run. That was bad. It should just be upfront - these limits exists, be sure before you start that you don't want to move them.

Quite good.

I trust it. I haven't tried it with thousands of virtual users. As true client, yes of course. We had arl 6000 true client users. That's 60 gigabyte memory. It's not a PC, so it's not large.

Quite responsive.

We were previously using LoadRunner for our customer, but we needed something that could be used in the cloud. I advised the customer to buy StormRunner Load as given the time frame it was clear from the beginning that we needed to use the true client scripts. We didn't want to set up the memory foot print for them so we had to go to cloud.

It was difficult because the Amazon stuff didn't work. I don't like to use Microsoft stuff. I was forced to put it onto Azure Cloud because that was the one that just worked out of the box. The Amazon launching died somewhere in the process. There was another error there as well.

I'm an HPE partner. I don't look anywhere else.

For all the in house stuff where we run into firewalls, it just gets bad. For public websites, it's perfect.

The flexibility makes it a viable solution.

• Load generator setup is not required so we can be running high concurrency tests in few minutes.
• Scenario setup for running tests was very easy.
• Distribution of the load from different locations was very easy.
• SiteScope and New Relic monitoring tools can be easily integrated with StormRunner Load.
• SLA configuration was available to monitor response times.
• Navigation breakdown report - to create a client navigation breakdown report.
• Real time graphs for monitoring results.
• Email reports.
• Benchmark- comparing previous test results with current tests.
• Anomalies detection.

Being able to setup and run 300,000 load tests using LoadRunner Performance Center takes around 1 to 2 hours when creating four scenarios of 75,000 each, including allocating/blocking load generators required for testing, initializing the fusers and running the test.

Running a 300,000 test was very easy using StormRunner. We just had to upload the script and create scenarios for 300,000 and run the test in 20 minutes.

Running back to back high concurrency test was very easy using StormRunner.

• Improved PDF reports and creating custom reports
• Real world- custom scenario setup
• Update existing scripts online without uploading them again
• Run time settings update in scenario

I've used it for five months.

None - there's no deployment required for running a load test.

During the initial days of high concurrency testing (300,000 and 600,000) we had issues with the StormRunner infrastructure e.g. graphs “disappeared” in the middle of a test, and HP had to give an online fix. Also, there were cases where tests appeared as “initializing” even though it actually started and HP again had to give an online fix. The StormRunner R&D team was very proactive in fixing the issues in very small turnaround time and supporting us running the high concurrency tests.

Scalability issues were seen during initial days of testing but it was resolved by StormRunner R&D team.

8/10.

8/10 - their team was very proactive in resolving the issues and provided hotfixes to support us running performance tests whenever required.

We were using Performance Center to run performance tests, so we had to switch to StormRunner to run high concurrency tests.

As StormRunner Load is a web-based application, it's simple setup, just registering users through an HP site.

In-house implementation and evaluation.

There were no other solutions evaluated.

StormRunner is one of the fastest-growing cloud based performance testing tools for running high concurrency tests very quickly.

It's in the cloud. Everything goes in the cloud. We needed something that's easy to set up in the cloud so we can use it directly there.

It's very easy to set up a load test, to start it and end it. It is valuable that it is very easy to use.

We are not benefitting a lot at this time because it has its bad parts.

It needs more features; a lot more features. Everything that's in LoadRunner Analysis should be built up in StormRunner; so we can use everything, every functionality and every feature all together.

It's stable. It's not perfect, but it's stable.

It is not really scalable.

We didn't use it that much. It was a demo session set up especially for us.

It's very east to set up. I did it directly myself just once.

We compared it to LoadRunner and Performance Center because we use that currently for load and performance tests. We cannot use this solution in the cloud. StormRunner is very rudimentary at this time, but it's a great concept. We hope that it will be thrilling.

We chose StormRunner because of the cloud. That's a great part of it.

Wait with StormRunner.

We've seen in the past where we have customers that use other performance testing products such as LoadRunner and Performance Center that they often have the need to do spike testing. Their testing for 1,000 virtual users running at the same time but before the application goes into production or before a big event, they need to scale up to 10,000, 20,000, 50,000, and so forth. We want to make sure that they can test to those specific limits and StormRunner allows us to do that.

I think the biggest issues that I've seen, and this is a personal view of mine, is that most of the HPE products have a common look and feel to them. I'd really like to see it be a little more customizable to a use and user standpoint. For example. I happen to be colors blind, so I'd like to see more vivid colors on the UI, and things like that. It would make it a little more flexible from the customer standpoint.

I was formally an HP employee, so I've used the HP products in the past. I also was a former Mercury Interactive employee which was acquired by HP.

It's been extremely scalable as far as the testing that we've done with our customers. They've all been really satisfied with the scalability of the HPE products.

We've gone through the standard customer support and it’s been good. It's not quite to the level that an R&D would be, because they really get really under the covers to fix things.

It really doesn't need to be as flexible as some other solutions because it's right out of the box, it's relatively easy to use. You open up, you create a test in ten minutes and then you're able to run it.

• The fact that you don't have to worry about the infrastructure setup.
• The fact that 1000's of virtual users can log on to the cloud without having to set up.
• Provides a solution for new or existing customers.
• Alternative to LoadRunner, for new or existing clients with agile.

At the moment, its a bit early for us to tell - does everything we need it to. HP is looking to expand to see what exactly it can be used for.

We did a trial since it was launched.

No issues with deployment.

No issues with stability.

We were only running a small set of numbers, but no issues.

It's not something we've really had to worry about - we were able to crack it open and begin.

The help files on the web are good and the video links/ guides are good.

We use LoadRunner extensively for Performance testing.

Setup was straightforward.

In-house implementation.

I can't calculate the ROI right now but I would assume a lot considering savings on infrastructure cost and license costs. It will still take some time to run a performance test but setup saves a lot of time.

We evaluate a lot of testing tools. NeoLoad, LoadRunner, we prefer HP.

If you're looking at an application that can be seen on the WAN and using agile approach, then its a tool that should be recommended and used.

• Ability to get started on the fly
• Reusability of existing HTTP/HTML scripts

I have been able to run several tests from outside the corporate LAN, which in the past used to be an infrastructure nightmare as it required opening up ports, disabling firewalls, etc.

It needs the ability to execute other protocols, especially the TruClient for Firefox without having to convert them.

We've used it for over a year.

There have been no issues with the deployment.

We have had no stability issues.

It's scaled to our needs.

Customer Service is immaculate.

Tech Support is immaculate.

There was no solution in place previously.

There was no set-up required.

It's done in-house, but there's no actual implementation needed.

There pricing and licensing options are very aggressive, but the holiday discount brought down the price further.

I think that StormRunner Load is the way forward and if HPE manages to support all protocols currently supported by LoadRunner/Performance Center eventually in StormRunner, it would be a massive game changer.

The charts dashboard, especially the results screen, is the most valuable feature. I’ve also configured the tests, so I’ve also used the test definition page, which is very easy to use, self-explanatory, and simple. The real value comes from the results screen.

StormRunner Load helped us evaluate the performance of the product version we were about to launch. It showed us bottlenecks, where our product reaches its limits, and different characteristics that affect this. For example, we had metrics we thought were affecting our response time. Initially we thought there were two metrics, but we found another significant metric we should have taken into account. Without StormRunner Load we wouldn’t have known about this "missing" metric.

I think the report page could be improved, although we have used the reporting feature. It wasn’t accurate enough to use as a report that I could send my managers. I had to take additional screenshots to help fill in the reporting. I actually, ultimately, generated a report on my own.

I've been using it for two months.

No issues encountered.

No issues encountered.

No issues encountered.

There was no previous solution in place.

This solution immediately helped us to determine the priorities for what to develop next and where we would reach our limits. Because we had a clear prediction, we knew when it would be urgent to develop features, in various cases. Before StormRunner Load, we didn’t have a clear developer roadmap, and now its very clear where we should invest, our weakest links, and what we need to do to strengthen weak links.

If you’re using third-parties for networking, cloud based servers, load balancer, VPN providers etc., all of them should be informed about the expected load. We had a VPN provider that was expecting thirty users per hour and calibrated accordingly, and the minute we started our load test it shut down. This third-party was not ready. Once we informed them that we were increasing our load, they increased their ability to support the load test.

No, this was my first choice.

It is very cost effective to start with a low number of virtual users for a short amount of time in order to verify that your company system is running properly. Start with a small load test, run it until completion, verify that you see the logs you intended to see, and all people involved in the environment are ready to see what they expected.

• The ability to spin upload really fast.
• The ability to create a script easily against an application.
• The ability to provision the load so it comes from multiple geographies across the world. 

The documentation could absolutely be improved and scripts. For example, during a performance test, the monitoring graph is not very clear as to what its representing. I wasn’t sure what the graphs represented so my guess is a lot of customers feel the same way.

One month - were doing a trial.

No issues.

No, the only thing I remember seeing as a “bug” when you hover your mouse over the graph, it will jumps around and doesn’t follow the mouse movement, other than that I don’t remember seeing anything from a stability perspective.

No, but haven’t really scaled it yet.

That's where the documentation could be really helpful, apparently I had an older version on my machine, which was creating conflict. If everything had gone as supposed to would have been simple but the documentation could have better and clearer.

Customers should understand the amount of time it takes to build a script - benefit of StormRunner as opposed to other cloud based Load testing tools is the ease of scripting. End users should understand the impact of the time it takes to build scripts. If StormRunner can save you 50% of your scripting, you need to understand how that translates into value. Expertise of StormRunner and LoadRunner includes these elements.