OpenText Enterprise Performance Engineering (LoadRunner Enterprise) Reviews

We use OpenText LoadRunner Enterprise for load testing. 

The tool is very easy to set up and get running. 

OpenText LoadRunner Enterprise needs to improve reporting. 

I have been using the solution for 13 years. 

I rate OpenText LoadRunner Enterprise's stability a nine out of ten. 

I rate the tool's scalability an eight out of ten. My company has 120 users. 

I rate the tool's deployment a nine out of ten. It can be completed in two to three days. 

I rate the product's pricing a three out of ten. 

I rate OpenText LoadRunner Enterprise a ten out of ten. 

We use the solution for performance testing, including load testing and stress and endurance testing. We have worked with Citrix, Web-HTTP/HTML, Truclient Protocols and Mobile Applications as well. It has a good user interface and is user-friendly.

It helped us to achieve our goals within the stipulated time and is a good solution for load testing. The integration was smooth, and all the help can be found in the Micro Focus help blog. The examples were helpful for new protocols and functions. 

The load testing, site scope monitoring, analysis, and graphs during execution are all useful features. It offers easy integration with third-party tools like Dynatrace, Splunk, etc. It also offers a customizable template for results. 

We'd like the product to include protocol identifiers whenever a tester wants to test a new application. They need to at least capture traffic and analyze and send a recommended protocol. 

They should give insights (passed/failed) with throughput achievable of the load test based on the throughput and errors in our previous tests without using the trend option for load tests. 

I have been working on the LoadRunner Enterprise more than four years.

Technical support is always available and ready to help.

Positive

The vendor is an expert and helps with all the setup and installation tasks.

LoadRunner Enterprise's most valuable features are load simulation and creating correlation for parameters.

LoadRunner Enterprise's reporting should be quicker, easier, and more flexible.

I've been using LoadRunner Enterprise for five to six years.

LoadRunner Enterprise is very stable.

LoadRunner Enterprise is scalable.

Micro Focus' technical support is fast and efficient.

The initial setup is very straightforward.

I would give LoadRunner Enterprise a rating of nine out of ten.

Overall, I am satisfied with this product.

All of the features are available with Micro Focus LoadRunner Enterprise.

The user interface is fine. It's intuitive.

I believe the data that demonstrates the automated correlations should be corrected. In addition, because it requires a lot of hardware, true client-based scripting should be improved. That needs to be improved.

I have been working with Micro Focus LoadRunner Enterprise for the last ten years.

The response time for technical support is extremely slow. They are generally not well-versed.

The technical support is awful.

There were no issues with the implementation process. It was okay.

The price is a bit too high.

I would rate Micro Focus LoadRunner Enterprise an eight out of ten.

Initially, I've been using it for small use cases, just to test scenarios of less than 1,000 users. I think generally it's been very good. My team has even deployed it for clients within banking. It's still a go-to tool; although, as far as SaaS goes, recently we have had more suggestions to go with Neosyde. 

I think the number one feature everybody likes is the capability to easily generate virtual users as well as the reporting. Recently, we are starting to look at things more from the diagnostic perspective as well as from the troubleshooting perspective. It gives us many more options for troubleshooting and presenting reports. The other reason why LoadRunner is quite popular for us is that it has a long track record. We know if we need to look for a solution we can still search and find a use case or a solution quite easily.

I like the new pricing model. It helps us to ramp up much better, especially when we were trying to use this for SaaS applications. They have a much more practical pricing model now. It allows us to break it down smaller and also build-up towards a price model that works for the client. I think that was a big bottleneck in the past — now it looks much better.

From a technical perspective, LoadRunner has always been good. You can trust that it can deliver. The big bottleneck in the past has always been the pricing model. Now, with the new approach, with the use of SaaS, we are currently in proposals to recommend LoadRunner as a solution for one of our government clients. We are doing an implementation there. 

I think LoadRunner is still getting into grips with me — maybe, I've not used it that much. It's not that popular on the cloud. Also, we have not tried this on mobile platforms with mobile virtual users.

I have used LoadRunner for quite some time — roughly 10 years.

Both the scalability and stability are strong points for LoadRunner. We have no complaints so far. Of course, there's always this concern around if we have sufficient use on the hardware to create the required scale for the number of users, but I think that's easy to workaround. This is what enterprise users do; we don't really have that much of a complaint there.

We work quite closely with the local team in Malaysia — they do their job.

Generally, the initial setup has not been much of a problem. If you have some level of intermediate knowledge on networks as well as some quick training on LoadRunner, you should be able to set it up within a week or two.

Proper training is important. If you have teams that want to use the product, you need to ensure that they go through the right training. Get your guys to sit through the LoadRunner training or get someone experienced to train them.

Make sure that your team trains before they go and apply the system because LoadRunner is not actually something that you do, plug-and-play. You do need a little bit of configuration, and it's not for beginners. It is meant for people with at least an intermediate understanding of networks, and an intermediate understanding of performance application — you need to have that. I would say it's always important to ensure that you work very closely with the development team. To get the best out of the tool, you need to have a solid collaboration. When you want to troubleshoot, you want to review or uncover the performance issues; you need to make sure that you work quite closely with the development teams as well.

On a scale from one to ten, I would give LoadRunner a rating of eight. We have not used it for global distributed testing, and we also don't know its full capability from a mobile perspective. That's an area that I cannot comment on yet, so I'm reserving my judgment on that. That's the reason why I am giving it an eight.

From my perspective, there's still a gap in terms of the area that LoadRunner is being marketed to. Its biggest strength, in my opinion, is the reporting. If they could keep the reporting, but give it a lighter engine to generate virtual users, that would be perfect. 

The primary use case for clients is that they often have large application development teams and application development projects that they needed to scale. So, for instance, if they were developing a new banking website and they needed to check that the application that sits on that website was scalable from a few hundred concurrent users to many thousands of users, they could test the load response using LoadRunner.  

That is what LoadRunner does, it does the performance testing and measures load-bearing response.  

I think, for me, the most valuable part of the product is the way you can do the basic testing. You can create the test script and then simulate thousands of users very, very easily. Instead of having to have lots-and-lots of systems that would emulate users, you just needed a couple to emulate tens of thousands of users. So the scalability of LoadRunner while it was testing scalability is really valuable.  

To improve the product, I think the integrations could be a little bit more slick. It does handle a lot of great integrations, but then some of them can be a little bit clunky to implement. The integration with third-party tools needs to be stepped up a little bit.  

As far as other things that need to be added, it has changed quite a lot recently, and I have not had vast amounts of experience with the latest version. So I am afraid it would not be fair for me to go further in expounding on that question. Things that I talk about may already have been included.  

I was a presales consultant and so I was kind of a technical consultant as well. I was working with the solution end-to-end for about seven years. My main focus was not LoadRunner for the entire time, but I gained knowledge of LoadRunner and I gave presentations about it. It has been about eight to twelve months since I last did anything serious with it. However, I am still familiar with the product.  

The scalability is really very good. In some ways, it is the purpose of the product: testing by use of scaling loads.  

The initial setup is pretty straightforward. But I have got to say, having worked on-and-off with LoadRunner over a period of time, I knew kind of instinctively how to set it up after a while. In other words, in my case, I would say it was simple. On the other hand, I think it the first time I tried to set it up it was a nightmare. After that, it was easy because I learned a lot about it. If I had to score it out of ten for initial setup with ten being the best, it would probably be seven-out-of-ten. It is not really going to be super easy for first-timers to deploy.  

The deployment could take quite a while, even when I was used to doing it. Getting the software installed and running is pretty quick and that is not a problem. But creating the projects and creating the test scripts can take a little while. To get up and running and doing stuff within it, it is probably just around a week. Doing it professionally with the integrations and with all the correct testing scripts, it can take a month and more. It really all depends on the purpose and how you want to use it.  

My advice to people considering LoadRunner is that if you are going to use the product, use it as part of your everyday application development lifecycle. Do not just use it right at the end, because it gives you some great insights during the development phase as well as at the end. You will end up writing cleaner application code with it. So bake the use of LoadRunner into your full application life cycle.  

On a scale from one to ten where one is the worst and ten is the best, I would rate this solution as between and eight and nine-out-of-ten. I could be slightly biased, having worked for the company that sells it. But it is a very good, professional solution. With the latest updates, it is very comprehensive and one of the best products of the sort. Let's say nine-out-of-ten because there is always room for improvement.  

We use LoadRunner for performance testing.

This is a product that has a lot of capabilities and is the most mature tool of its kind in the market.

In the DevOps model, performance testing has become a bottleneck. This is because, after the completion of a sprint, people are in a hurry to send it to production but it first needs performance testing. Whenever there is a code change, it takes a lot of time to rescript and debug the script.

The TruClient protocol works well but it takes a lot of memory to run those tests, which is something that can be improved. Basically, it is too resource-intensive.

Performance testing needs to be better integrated into an agile framework.

There should be a way of automatically increasing the load generators on the cloud, without specifically having to spin up the agent and configure it. There is a third-party tool that does this. 

I have been using LoadRunner Enterprise for nine years.

Although it is stable, the whole performance testing process becomes very slow because of its complex scripting and having to rework the scripts. Ultimately, this will become obsolete if it is not improved.

LoadRunner is a scalable product. We have a team of four or five people who use it.

The technical support is very bad. It seems that people will ask a lot of unnecessary questions just to bide the time. We are very frustrated with the support team.

This is the only tool that I have used for performance testing. It is the tool that I use most of the time in my role.

The initial setup is fine. Deploying LoadRunner is quick but to set up the performance testing itself takes a lot of time.

When it comes to organization, people compare automation testing with performance testing. Automation testing is something that is very easily integrated within an agile and faster delivery framework. The scripting in automation testing is robust because it is GUI-based. When it comes to performance testing, it is request-response-based and the scripts are not very robust in some of the application platforms. Because of that, people feel that performance testing is a bottleneck and it takes a lot of time.

I would rate this solution a seven out of ten.

The solution is a very user-friendly tool, especially when you compare it to a competitor like BlazeMeter.

The custom meter is nice. It has a lot of features.

When compared with BlazeMeter, I use the plain data. In the cloud after one year it has been very good.

With reporting, we will see the door unlock on the main portal very quickly, because LoadRunner has very good analysis tools. You can analyze data and get the error data as well. You can merge them together and dig down into specific points of time. It's great for correlating drafts within the number of users, between accounts, and with support. These functionalities are not there in BlazeMeter.

The solution is a very expensive tool when compared with other tools.

The stability in some of the latest versions has not been ideal. They need to work to fix it so that it becomes reliably stable again.

The cloud solution of LoadRunner is not user-friendly when compared to BlazeMeter. They need to improve their cloud offering in order to compete. It also shouldn't be a standalone tool.

I've been using the solution for about one year now.

In terms of stability, it depends on what you are using. Sometimes version 5.3 and the newer versions are not stable. The latest versions we are finding are not so stable when compared with the previous versions we've used, so some glitches are there. They need to rectify that. It was stable for two years, and now it's not.

The solution is scalable, and it's based on the number of licenses you have. In comparison, with BlazeMeter, I ran thousands of users, because it's very cheap and we could scale up the number of users easily with very little overhead.

In my experience, I've used BlazeMeter to scale up to 5,000 users. With OpenText, there are not more than 2,000 users.

In OpenText, I have worked with various types of clients. Some clients have platinum customer status, and some have gold. For those levels, the support will be there. At platinum, technical support is very helpful at updating their support and the support is good.

I also use BlazeMeter.

With LoadRunner, I use it with a paid tool, and since I am following the protocol, I need it to be easy to use. Whereas with BlazeMeter, we use it with JMeter. We need to use it sometimes if we want support. We need to configure some properties or some customers' ratings before we can use it.

The solution needs to reduce licensing costs. Its main competition, for example, is free to use, so I'm sure it's rather difficult to compete with it on a cost level.

We're partners with OpenText.

I haven't found many products in this particular niche that have compared to JMeter and BlazeMeter tools.

I'd rate the solution eight out of ten.

I suggest other potential users review OpenText. If the client has the budget for the solution, I'd recommend it. If they don't have a budget, I'd suggest they instead opt to look a freeware solution, and I'd suggest they evaluate JMeter or BlazeMeter.