OpenText Enterprise Performance Engineering (LoadRunner Enterprise) Reviews

ALM centralizes everything. It allows you to work out how well you are doing project-wise because you see the number of scripts done, the number of tests run, and whether you have mapped all your requirements to it. You can produce metrics there fairly easily for your line management and higher. So, overall, it is better than people using Excel spreadsheets.

Performance Center is good because it allows you to share resources, which wasn't happening with Load Runner. With Load Runner, everyone was very specific. I've just got these controllers and their mine and I might only be using them five percent of the time but I need them tomorrow. And I can’t allow anyone else to use them because it will disrupt my schedule.

With Performance Center, you start to get into position where people can say, "I need to run a test, how many assets are available? When can I plan to do it?"
It also provides discipline because you stop getting people saying, "We're ready to do performance testing," because they've got to schedule the test. They've got to use that period when they've scheduled it. If they don't we pull it back and somebody else can use it. You get a lot of people screaming they've lost their slot but what you've proven to them is that they're not ready for performance testing.

It's very good from that point of view. It focuses people's minds on actually using their time effectively.

I have been using ALM for eleven years. I used it when it was version 9.2 and continued with a lot of versions, all the way through.

We picked up Performance Center when we started introducing Load Runner. We kept that together until we realized we were had too many instances and it would be better strategically to go with Performance Center. I have been using it for ten years.

HPE Quality Center ALM is stable. It obviously has not got the attractiveness of Octane. As going forward, Octane probably does now take it to the next step.

The one thing I always said about ALM, and I'll say this to everybody. The worst thing about it is it did not have zero footprint on your PC. The amount of effort and the cost to upgrade to the next version, the amount of problems that it gave us in terms of trying to put a patch on, because it was particularly essential, was really bad for the business.

We had many different PC models out there on people's desks, so it wasn't just a case of patching or building a new MSI package for one PC. You had to do it for a whole range and then you had to deploy them at exactly the same time or somebody would find that they couldn't use Quality Center.

Octane, now being zero footprint, is probably going to be one of the biggest cost savings I see.

Performance Center seems to be stable. It's probably being utilized far more readily than, say, even Unified Functional Testing.
There are issues with it that mostly seem to be environmental. You'd be surprised how many people think they know about how to do performance testing and then they start using a server that's in one area of the UK to try and run a performance test on servers in another country.

I’m thinking, “why are you running such a transaction load across our network.” Whereas, they should really be in the local area. So, with Performance Center, most of the issues are more user-based. Technically, it seems to meet the task that you need it to do.

Without a doubt, both Performance Center and ALM are very scalable.

Sometimes support is good. Sometimes it's not so good. Sometimes you hit an issue and trying to get across the message of what the issue is, and then trying to get an answer back, can be a bit of a challenge sometimes. You hit an issue that everybody else has hit and it has a solution, then you get the response back. But in the majority of cases, the people that are on the case for you tend to do their best to try and answer what you've given them.

Adaptability is what I look for in a vendor. It tends to pull the others in. A good contact, ready to listen, to really know how to deliver what you want. Someone who can listen to what your problem is or what your challenge is that you need the tool to resolve. And if you're willing to adapt to that, then the tool might not be 100%, but it might make it's way there. If you're fixed in your ways, and say, "this is what our tool does, this is all that it's going to do," then to be honest, why continue?

The biggest issue is that ALM is a thick client and you can't patch it, because you've got hundreds and hundreds of PCs. Several different standards are on people's PCs. You can’t do it. You leave it until there's a big release and then you take a massive program to deliver it. Get rid of that thick client bit and you could patch on the server and it could be up and running the next day. Which is the neat bit about Octane.

The setup of Performance Center seems fairly reasonable. No real shakes about it. Obviously, you've got to have VuGen on the PC. It tends to have to be a meaty PC, but then you are running performance tests. My biggest challenge with Performance Center is having people who claim to do performance testing or know how do to performance testing and they're still wet behind the ears.
A good performance tester needs to have a good 18 months experience with them. They need to have done things with Performance Center. Delivered projects. They need to use SiteScope. They need to use analysis tools on that network. They need to know how to get the best value out of the tool. Somebody who's just come for the first time has probably done a week or two-week training course and says, "I know how to performance test."
They get results back and say, "We ran it for a 100 users and it failed." Well, okay, where did it fail? Where's the analysis that helps us fix the problem? And we didn't get that, which they would have done if they'd known to implement the additional bits like SiteScope against it.

So, with Performance Center, it's a skill issue for the people that are using it. Again, one of my guys says, “I’d like to see people be able to grade themselves in Performance Center or even in performance testing, "I'm at a Bronze level. I'm at a Silver level. I'm at a Gold level." Then you know how effective that person is going to be.

We use the solution for our banking systems.

Micro Focus LoadRunner Enterprise is on our own computer. We do all the development of scripting on our own computers. When we run the solution, we can run it on the cloud or in LoadRunner Enterprise.

Micro Focus LoadRunner Enterprise is easy to use and has flexibility that allows it to be used on a variety of applications.

The solution has something called True Client which makes it easy to create scripts if we have a big application with many steps. True Client is helpful when we record our scripts and we have the possibility to generate a standard script from the True Client script. I use True Client a lot.

The solution can be improved by adding more AI to the True Client feature.

The cost of the solution is high and can be improved.

I have been using the solution for over 25 years.

There are some problems with the solution's stability, so it's quite stable, but not totally stable. I give the stability an eight out of ten.

I give the scalability a ten out of ten.

Micro Focus LoadRunner Enterprise is easy to set up, record, and use. We have a department that is responsible for deployment.

I give the deployment a ten out of ten.

The implementation is completed in-house.

We found that the return on investment is around 50 percent, even if the tool is expensive. We have found bugs that would have been critical if we had pushed the application into production. The solution has made up for its cost by saving us from pushing faulty scripts into production.

I'm not sure if other similar solutions are cheaper, but Micro Focus LoadRunner Enterprise is expensive, and could easily be 20 percent cheaper.

I give the cost a one out of ten.

I give the solution a ten out of ten. Micro Focus LoadRunner Enterprise is the best in the market, depending on what it is being used for. For API testing, we can find something cheaper. But the solution is good for that as well. For bigger applications that are Gooey-based, it's the best option.

Creating a script depends greatly on the type of application we have. If we have an API system, it will likely take less time to create a script since the developers have likely already set it up for us to use. However, if we have a lengthy application, it may take us days to create a single script.

We have between five and ten developers using the solution.

I recommend the solution, but it's expensive and only a big company could afford it. A small company wouldn't have the capacity to use the solution or the money to pay for it.

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.

It provides a different platform for testing in an organized fashion. One of the big things is data warehousing, data analytics, you want to get from being reactive to proactive to predictive. Those are the progressions that we want to make. It's going to be extremely difficult when you start to incorporate testing platforms, testing techniques, to tooling, into pipeline, into any of these DevOps pipelines. If we can't collect the data, if we don't really know what's going on, then it becomes very hard to make testing decisions from tooling to technique to platforms. 

Performance Center innately provides you the ability to manage those assets. And it's also a different type of testing, independent of something that might be more unit based. We want to be able to test at the integration or the system level, which is a completely different approach to testing compared to a developer who may be doing something very, very low-level. Instead of changing the class.

We want to make sure that all these areas of testing are not just being done, but they're also able to be audited. Because, without access to the data, it makes it very difficult to implement solutions going forward. Whether they're new or they may be something that's up for modernization to keep up with DevOps and pipelining.

It has to be fully integrated into pipelines, it needs to be DevOps friendly. It needs to be easily digestible by management, and certainly developers. It's a developers' world, as it should be. They're the ones who create the applications and solve the problems in those applications. So it has to be positioned to be something that allows a team to make better decisions, to move through that progress I mentioned before, from reactive to proactive to predictive. Once you get the predictive you can make better decisions on how you should be teasing things, and Performance Center will have to follow the same trajectory. It has value, but the value needs to evolve and mature along with other aspects of application development.

Performance Center, in our company, is used for important applications where we have a lot of users, or special needs for performance that are important.

We have a central team that implements the scripts and executes the tests. It depends on the years of experience of the users. The investment goes down, then we have more issues. Then money is spent and then investment goes up. So it is a curve. Everything is going up, as it is in ALM. ALM is still a growing market.

With Performance Center, the version upgrade is easy. You just have to roll out the new patch or the new version. It is much easier. I'm not really the right person to say, because I run the environment. We have a specialized team that does development.

I’ve been using Performance Center since 2007.

Performance Center is more stable than ALM. We roll out a version, and I think it fits for our clients. If it is a very early version, then we have to implement a patch. Afterwards, it is quiet, hopefully, for at least one or two years.

For Performance Center, you have to add additional load generators, and then you can do more. I think it is a matter of the price, in terms of how many machines you can buy.

For such an experienced team as mine, who have been with the product for over ten years, sometimes working with technical support is not that easy. Support does not have our knowledge. It takes a while to train them in what our issues are and we have to connect to second or third level support.

The collaboration between us and HPE, especially over the past ten years, has been very good. This is the most important thing when looking at a vendor. For that reason, I try to bring in more HPE products, if needed.

• Integration with the majority of enterprise tools
• Scripting
• Reporting
• Admin Console
• Reporting & Analysis tool

This helps us to uncover some very high and critical performance-related defects, and keeping almost zero production issues related to the performance of applications since then.

Almost all the areas improve drastically with each version; however, the correlation of scripts, analysis and reporting can be further improved. Their technical support could also be improved. Recording of the latest applications is an area for continuous improvement.

I've used it for the last 15 years, and for the last nine years at enterprise level.

No issues encountered.

No issues encountered.

No issues encountered.

Mercury support was very good compared to HP, however they are getting better day by day.

It was straightforward initially with v8.1 and various FPs for 8.1. However it was very complex with v10. It was due to the way our security suites were designed that made it very complex. The design stage took one month, and implementation was two months, and we had one month dedicated support from offshore.

It was with a mix of an in-house team and vendor support. The vendor team is necessary for the initial setup, and upgrades can be done in-house, but major upgrades need vendor support.

We carried out various PoCs for different market leading tool sets, and chose HP Performance Center because it offers better test suites for our enterprise tools, ease of integration, and it had more collaboration with our existing tool sets. Also, the technology, current & future demands for various applications, was better than the other opetions and they offered better support arrangements.

It's generally for enterprise level, however they now offer a SaaS version for smaller companies or clients.

Performance of load test applications, reliably, and with good reporting.

We have high confidence that the results are reliable. It's helped catch multiple bugs before they've gone to production. And we're able to more confidently release software into production, just more confidently release code.

I'd like to see better reporting, ultimately, and analysis. I'd like to see the analysis more accurately pin-point where these issues are; a little more feedback immediately in terms of the anomalies that we're seeing during the testing, so we can get alerted much quicker, instead of blowing a whole bunch of our day to test data during a test.

The reporting could be a lot better. It's cumbersome. The VuGen takes a long time to load up, and edit and execute things off those. So a lot of the basic infrastructure.

We've had a few crashes, but overall they seem to be more of the aging architecture, the hardware's not as reliable. A few software bugs in there, which we have to work around. But overall, it's been pretty reliable when you think about how much load goes through it and the number of people using it.

We've scaled it up to, well, to our limits at least. A good 1500 users and some 10 million transactions, or something like, that per hour. It's generally handled that pretty well. We're looking forward to moving into StormRunner next.

The tech support seems to be pretty good. There have been a few problems that they haven't resolved, but they've led me in the right direction to eventually figure it out on my own. It's very difficult for them to understand all the wide range of applications we use. So I'm really impressed with how ultimately knowledgeable they are, given that they don't actually use all these applications that are out there.

I wasn't involved in the initial setup but I've been involved in all the upgrades. They've done it multiple times. Each upgrade seems to be adding a lot more features. It seems like the pace of development has picked up in the last couple years especially, and we've been impressed with the direction that the product's going.

The upgrades actually were fairly complex for my team. The last one, they were actually giving up for a while. It turned out that there were some database versions that were incompatible. Eventually, once we were able to get connected with the support, we were able to get most of it worked out.

There was a big upgrade with the 12.5 version that was a little slower. But everything else has been very smooth since then. Still, it's difficult. Everybody's come to count on that software being at a certain version.

The most important criteria when selecting a vendor are, I suppose, support, and the reliability in the industry.

They have a good road map for moving forward. It's going to be integrating with a lot more other products that the DevOps world is starting to push upon us.

It's not quite perfect. It's still the best in the market. It holds up to a lot of the scrutiny that the developers constantly throw at us.

There have been a few issues, especially around the scripting and the IDEs, handling of some of the protocols, that still don't perfectly match with what we have in production. But overall, we're able to pretty well defend it. You can almost always reliably pull up the application, and the response times seem to match what we have coming out of LoadRunner.

I would definitely advise looking at Performance Center, it's still the best in the breed. Just make sure that you have a good team in place that can implement it.

We are using Micro Focus LoadRunner Enterprise for performance testing one of the client's ERP solutions.

Micro Focus LoadRunner Enterprise supports a lot of technologies. The existing performance testing that this tool is capable of is good. The protocols that are available are widely varied when compared to other performance testing tools. 

Micro Focus LoadRunner Enterprise needs to add more features for Citrix performance-based applications testing. This was one of the challenges we observed. Additionally, we experienced some APIs challenges.

I have been using Micro Focus LoadRunner Enterprise for approximately four years.

The stability and performance of Micro Focus LoadRunner Enterprise are very good. It is a very established tool and there are not any issues with the reliability.

The solution is highly scalable.

The support from Micro Focus LoadRunner Enterprise has been excellent.

We tried NeoLoad previously. We found that NeoLoad is a good competitor to Micro Focus LoadRunner Enterprise.

The price of Micro Focus LoadRunner Enterprise could improve, it is expensive.

When comparing Micro Focus LoadRunner Enterprise with the competitors that are coming into the market, I would look for an open-source version of this tool, if possible. The cost is one thing that is preventing people from using Micro Focus LoadRunner Enterprise. 

Some of the upcoming protocols are coming into the market, some of these are not supported by Micro Focus LoadRunner Enterprise. I can easily choose NeoLoad and complete what I need to with it. 

Micro Focus LoadRunner Enterprise is still evolving in the coming DevOps sector,  once the CICD architecture comes in, we will see more changes. I presume it is not up to date from a CICD support perspective.

I rate Micro Focus LoadRunner Enterprise a five out of ten.