OpenText LoadRunner Enterprise Reviews

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.

What I really like is our team's core competence in building good tests that really do find issues, because of our full-time dedication to it. We have Performance Center as a platform to share with others that don't do performance testing full-time, so that they in an agile fashion, on demand can go ahead and get real issue-finding testing done; then to go ahead and have that pulled into trending reports so that even subtle differences or trends over time are found and not just game-changing defects. Again, it's a platform to get expert level things done for the masses.

It allows us to on the reporting end show how even though we don't have a smoking gun on this release, and it made everything so terrible that we've got real quality issues, we know when it started and that it's only getting worse. When you're tracking many subtle interactions, this is helpful.

I know there are integrations with continuous testing. It's got tie-ins to some of the newer tools to allow continuous testing. I'd love to see us not have to customize it, but for it to be out of the box.

I have some concern over its foundation for utilizing cloud testing hosts in the most integrated fashion. For example there is reliance in AWS to utilize default VPC, and also there is not deep knowledge about utilizing *nix hosts though they are supported.

I have used this solution at four different places starting 13 years ago.

It's good. It's been around a long time and we've been using it a long time. It's stable.

We're up to 60,000 users. It's got a good system for being able to take a vast amount of data that you haven't put into a particular report and chug through it. It could take a while, but it's stable at that.

It comes up periodically; typically when we're doing something we haven't done before. We actually have a combination of support through them and one of their value added re-sellers, AVNET. We actually get level one support through them, so it's a partnered supported arrangement.

Typically AVNET can handle anything unless it's truly about requesting a new feature or enhancement. You need to get back to the product management and developers to request such things.

It has many tiers, it's not a single system thing. You definitely have to take the time to architect it correctly, to have a full topology. I've done it a few times.

As professionals, we're supposed to be some what tool agnostic. We'll find a way to get it done. That said, it's a mature player in the space. We do enjoy some long time knowledge about squeezing the good stuff out of it.

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.

We use this solution for performance and load test different types of web-based applications and APIs. We want to make sure that before any application or any upgrade to an existing application is made available to an actual user, it is sufficiently tested within the organization.

We want to ensure that if there is a high volume of users, they have a seamless experience. We don't want them to experience slowness or an interruption in service, as a result of an increase in the number of users on the web service or website. Essentially, we test to guarantee that all of our users have a good experience.

When it comes to delivering enterprise-level testing capabilities, this solution is really good.

Using this tool, we are able to test an application end-to-end from any area. Specifically, we are able to test our applications that are used across geographies. This includes worldwide locations starting from one end of Asia to the other end of the Americas. Geographically, we have full testing coverage for virtually all of our enterprise applications.

In terms of application coverage, there have been very few or no applications at the enterprise level that we have not been able to test using this tool. I think there is only one, but that was a unique case. Apart from that, at an enterprise level, in terms of coverage and geographically as well as technically, we have been able to test everything using this solution.

OpenText has a platform where I can share what is good and what further improvements I can make. There is also a community where we can leave feedback.

As an admin, I have the ability to copy all of the details from one project to another. However, I don't recall functionality for cross-project reporting. If there are two projects available then I cannot run a load test or report metrics from the other project.

LoadRunner Enterprise offers multiple features to perform a deep dive into a project. For example, we can see how many load tests of a particular application were run over a certain period of time. We can also see what scripts and tests were built over a time period. There is lots of information that it provides.

It is very important that we are able to drill down into an individual project because we sometimes have to look into what set of tests was executed for a particular project, as well as how frequently the tests were run. This helps us to determine whether the results were similar across different executions, or not. For us, this is an important aspect of the functionality that this tool provides.

One of the major benefits, which is something that we have gained a lot of experience with, is the internal analytics capability. It has multiple graphical and analytical representations that we can use, and it has helped us a lot of times in pinpointing issues that could have caused SEV1 or SEV2 defects in production.

We found that when we ran the load test, those issues were identified by using the analytic graphs that LoadRunner provides. Based on this knowledge, we have been able to make the required corrections to our applications. After retesting them, we were able to release them to production. This process is something that we find very useful.

In terms of time, I find it pretty reasonable for test management. There are not too many things that we have to do before starting a load test. Once one becomes good at scripting, it does not take long. Of course, the length of time to run depends on how big and how complex the script is. Some load tests have five scripts, whereas some have between 25 and 30 scripts. On average, for a test with 10 scripts, the upper limit to set it up and run is a couple of hours.

Overall, we don't spend too much time setting up our tests.

One of the most valuable features of this solution is recording and replaying, and the fact that there are multiple options available to do this. For example, a normal web application can be recorded and replayed again on many platforms. Moreover, it can be recorded in different ways.

An application can be recorded based on your user experience, or just the backend code experience, or whether you want to record using a different technology, like a Java-specific recording, or a Siebel-specific recording. All of these different options and recording modes are available.

The scheduling feature is very helpful because it shows me time slots in calendar format where I can view all of the tests that are currently scheduled. It also displays what infrastructure is available to me to schedule a load test if I need to.

Something that is missing is a platform where I can share practices with my team. I would like to be able to inform my team members of specific best practices, but at this point, I can only share scripts and stuff like that with them. Having a private community for my own team, where I can share information about best practices and skills, would be helpful.

OpenText needs to improve in terms of support. With the same support plan but when the product was owned by HP, support was more responsive and better coordinated.

The monitoring and related analytical capabilities for load tests should be brought up to industry standards. This product integrates well with tools like Dynatrace and AppDynamics but having the built-in functionality improved would be a nice thing to have.

I have been using OpenText LoadRunner Enterprise for approximately 15 years. It was previously known as Performance Center and before that, it was simply LoadRunner. In terms of continuous, uninterrupted usage, it has been for approximately nine years.

I am a long-time user of OpenText products and have worked on them across multiple organizations.

Our tool is hosted on-premises and we have not faced stability issues as such. One of the problems that we sometimes experience is that suddenly, multiple machines become unresponsive and cannot be contacted. We call these the load generators in LoadRunner nomenclature. When this happens, we have to restart the central server machine and then, everything goes back to normal. That sort of issue happens approximately once in six months.

Apart from that, we have not observed any stability issues. There are some defects within the tool which from time to time, we have raised with OpenText. If they have a fix available, they do provide it. Importantly, it does not make the product unusable until that is fixed.

This product is easy to scale and as a user, we have not encountered any such issues. Over time, if I have to add more machines to monitor, or if I have to add more machines to use during a load test, it's pretty straightforward.

If I compare it with other tools, I would say that it does not scale as well. However, as a user, it is okay and I've never faced any issues with adding more machines.

Whenever we have any support required from OpenText, the process begins with us submitting a ticket and they normally try to solve it by email. But if required, they are okay with having a video conference or an audio conference. They use Cisco technology for conferencing and they are responsive to collaboration.

Unfortunately, technical support is not as good as it used to be. From an end-user perspective, coming from both me and several of my team members, we have found that over the last year and a half, the quality of support has gone down a couple of notches. It has been since the transition from HP to OpenText, where the support is simply no longer at the same level.

The level of support changes based on the plan that you have but our plan has not changed, whereas the responsiveness and coordination have. Generally speaking, interacting with HP was better than it is with OpenText, which is something that should be improved.

I have not used other similar tools.

I have not set up other tools, so I don't have a basis for comparison. That said, I find that setting up LoadRunner Enterprise is not very straightforward.

Whether it's an initial setup or an upgrade to our existing setup, it's very time-consuming. There are lots of things that we have to look into and understand throughout the process. It takes a lot of time and resources and that is one of the reasons we are considering moving to the cloud version. Ideally, our effort in upgrading to the newer versions is reduced by making the transition. The last couple of upgrades have been very consuming in terms of time and effort, which could have been spent on more productive work.

To be clear, I was not involved in setting it up initially. Each time we deploy this product, we set it up as a new one but use our older version as a base. Prior to the configuration, we have to update it. However, it is older and it does not upgrade, so we have to install it as a new version. I do not see a significant difference in time between installing afresh and upgrading an existing installation.

If I am able to identify the needs and what is required, from that point, it takes almost the same amount of time whether it is a clean install or an upgrade. The biggest challenge with LoadRunner Enterprise is to identify the database that we're using and then upgrade it. As soon as the database is upgraded successfully, 70% to 75% of the work is complete. It is the biggest component, takes the longest, and is the most effort-consuming as well.

I am involved in the installation and maintenance, including upgrades.

I have not been directly involved in price negotiations but my understanding is that while the cost is a little bit high, it provides good value for the money.

I did not evaluate other tools before implementing this one.

At this time, we do not make use of LoadRunner Developer Integration. We are thinking of migrating to the latest version of LoadRunner, which probably has the LoadRunner Developer functionality. Once we upgrade to the new version, we plan to use it.

We are not currently using any of the cloud functionality offered by OpenText. In our organization, we do have multiple applications that are hosted on the cloud, and we do test them using LoadRunner Enterprise, but we do not use any component of LoadRunner Enterprise that is hosted on the cloud.

I am an active member in several online communities, including LinkedIn, that are specific to performance testing. As such, I have seen different experts using different tools, and the overall impression that I get from LoadRunning Enterprise is that it offers good value for the price. The level of coverage in terms of scripting and analysis had helped to solidify their position as a market leader, at least a decade ago.

Nowadays, while others have closed the gap, it is still far ahead of other tools in the space. My advice is that if LoadRunner Enterprise can be made to fit within the budget, it is the best tool for performance testing and load testing.

I would rate this solution an eight out of ten.

Our primary use case for Performance Center is testing the performance of all of our applications.

One thing that always fails at our company is that after you have checked in an application then it usually crashes in some way. You get some strange error message. We found out you can open the test you have set up and usually, it works without the error the second time. So you just close the application test and open it again, and then it is okay. So that is quite confusing if you are new to the product, but you do not care about the inconvenience or even notice it after using the tool for a while. It does not seem very professional and it is really a buggy behavior that should be fixed.

One feature I would like to see included in the next release of Performance Center would be to be able to run more fluidly with True Client so you could put more virtual users in Performance Center. That would help. I'm not sure how easy it is to compile something like that, but it would be valuable.

We've been using Performance Center for about a year.

We have had some problems with instability. At one point Performance Center suddenly went down for two days, but usually, it works. It works okay now and has not been a problem, but it was worse in the beginning. They have changed something, so it is better now than it was, I think.

The scalability is good enough. Sometimes we get a message from the generators that they are at 80% or more capacity. That is an error we get quite commonly. We only have eight gigabytes on the generators and it is recommended to use 16 gigabytes. I guess that is likely the reason why we have this problem. This happens a lot more often when we are running TruClient. The 80% capacity error comes up very fast in that case. We can not run many users with TruClient at all.

It is not usually me who calls tech support but I got the impression that the team is quite pleased with it. Usually, it is good. On the other hand, we have had some problems now that are not resolved. For example, one of my applications is not running at all because we are running on version 12.53. There was some problem with the REST (Representational State Transfer) services and the coding part of our REST services. We were using a very old encoding version that we are not using anymore. We stopped using it a long time ago. But it was still supposed to be compatible in 12.53, and that is what we are using. I know the problem was fixed from version 12.56 and up, but we have not been able to complete the upgrade. 

I'm able to run the tests on the application locally, but not in Performance Center. So we are waiting for this upgrade at the moment to resolve these issues.

We are currently using 12.53 and we are trying to upgrade it to 12.63 but it looks like there's a problem with the upgrade. We would like to switch to take better advantage of some features that are currently difficult to work with. We used LoadRunner concurrently for a while, and while it was a good product there were things about Performance Center that we prefer.

I was not included in the process when they installed the solution, but it took quite a lot more time than I would have expected. I guess, based partly on the length of time it took, that it was not very straightforward to set up and must have been a bit difficult. The other reason it does not seem easy is that the team has tried to upgrade now two times now and both times they had to roll back to the previous version. We'll see when a fix is issued and they try to upgrade again if the issue is solved. It looks like there are problems with connecting properly. The team has a ticket in with Micro Focus about the problem, but we are not sure what the problem stems from and a resolution has not been provided.

I'm not quite sure about the exact pricing because I do not handle that part of the business, but I think the Performance Center is quite expensive. It is more expensive than LoadRunner, although I am not sure how many controllers you can run for the same price. They said Performance Center was costing us around 40 million Krones and that is about 4 million dollars. But I think that was with ALM (Application Lifecycle Management) as well and not only for Performance Center.

Before we used Performance Center at all, we used LoadRunner (Corporate version, 50 licenses). But now we changed over almost entirely to Performance Center and we are phasing LoadRunner out. For a while, we were running both at the same time to compare them. The nice thing is that we do not need to have many controllers connected with Performance Center. The bad thing is that more than one person may want to use the same generator. So sometimes we have problems. I guess we had the same problem before when we used LoadRunner because everyone can't run a test at the same time.

There are some good things and some bad things about Performance Center in comparison to LoadRunner. The good thing is that you are able to share the screen while you are running a test. On the other hand, you do not get all the same information you get with LoadRunner when you run the tests. After you have done the tests, you can just copy the completed file and you get the same test results as if you had run on LoadRunner. So that is not really a problem. But when first running the Performance Center application for testing, I missed some of the information I got from LoadRunner. It is just a different presentation.

The advice I would give to someone considering this product is that they should try LoadRunner first before they start using Performance Center — especially if it is a small company. They need to know and be able to compare LoadRunner to Performance Center in the right way. After you have used LoadRunner then compare Performance Center. If they are part of a small company and they expect to expand they will know the difference. If they are already a very big company, they can save some money by using Performance Center directly. We are quite a big company, so Performance Center makes sense for us.

On a scale from one to ten where one is the worst and ten is the best, I would rate Performance Center as an eight. It is only this low because we have had so many problems here installing it and upgrading it. Sometimes it runs very slow just to set up tests, or it just crashes. Like when setting up a spike test, you start using the spike test process and it suddenly crashes after you have almost finished everything. Executing the tests were a lot easier and more stable in LoadRunner.

You can manage to make Performance Center work, but you have to be patient.

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.

• 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.

• It helps you to build custom design application simulation models that enable the performance test engineer to assess an enterprise, multi-tier, heavily-distributed, high-traffic application on how the application for that particular release meets its non-functional test requirements and SLA thresholds, which are key business-transaction response times.
• It tell you your applications' CPU computational power usages under various conditions such as stress, volume, and scalability.
• Its distributed nature will let you choose load generators that can be geographically located anywhere, thus traffic simulations from multiple locations make it possible to create a real production scenario.
• The true advantage of Performance Center is the ability to enable multiple engineers to do design and validate their script locally, but to execute them globally by using global resources spread across an organization.
• The other advantage is the integration with HP SiteScope which lets you to perform deep-dive monitoring of your application under test during your test execution for live health analysis using several readily available monitoring templates.

Some of the key-business and mission-critical applications released earlier into production were having issues in terms of key business transactions running slowly, which were impacting the end-user experience. The slow business transactions were causing grief to several customers, which eventually led to customers being moved onto different competitor products, causing revenue loss. There was increased downtime of applications in production due to poor application performance.

With the help of HP Performance Center and LoadRunner, we were able to critically evaluate the applications performance and stability, and were assured that each application that was released into production was performing better and meeting all SLAs, including transactional response times and system and platform resource utilization.

We have received excellent feedback in one specific instance where a customer came directly to me, and said that they are seeing much better transactional response times, which helped them serve customers faster, and now they are seeing their customers coming back.

Integration with other APM tools like DynaTrace or AppDynamics is a little tedious. Plus, support around cloud solutions and architectures needed to be improved.

I have used several versions of this product for over five years, alongside HP LoadRunner.

No issues encountered.

No issues encountered.

No issues encountered.

It's excellent.

It's excellent.

As a person who has been in the performance engineering field for several years, I have used several similar products. However, Performance Center and LoadRunner offer unbeatable support across different protocols, including SAP and AJAX true client.

Also, its ease of use in designing and reusable custom automated performance frameworks is unbeatable. Its support in designing frameworks and scripts for load testing message queues, web, and web-service protocols are quite remarkable.

It offers different types of users for people who come from different programming backgrounds i.e. if you are predominantly a C programmer, you can write a lot of custom API’s using C, and similarly, if you come from Java programming you can use your Java skills in custom API implementation.

It was straightforward.

In-house.

It can lead to the generation of a very high ROI if you have the right people with the right expertise of the tool set.

It is a bit highly priced. However, better products with a better quality can come with a good price.

It is definitely one of the best products available on the market. Definitely programming knowledge around C programming would be greatly advantageous.