OpenText Enterprise Performance Engineering (LoadRunner Enterprise) Reviews

We primarily use OpenText LoadRunner Enterprise for performance testing. There are three main components: the Fusion Loader, the analysis part, and the Vision, which we use to record diverse scenarios. We configure it for multiple users. The controller is used for load testing, stress testing, regression testing, or bundling various scenarios. Once the tests are complete, we analyse response time.

Depending on the requirements, LoadRunner enables load testing for distributed applications or services. Generally, we execute load tests for around three hours. Performance tests can span eight to nine hours but vary depending on project specifics. We have three different approaches for performance testing based on project requirements.

We have a different option. We can schedule our scripts to execute at a specific time based on the requirement with a specified number of users. LoadRunner offers such facilities which other tools lack.

OpenText helps us identify the amount of load testing impacts on overall performance. We can measure metrics like hits per second and detect deviations or issues through graphs. We can filter out response times based on timings and identify spikes in the database or AWS reports. We can also analyse long-running queries or reasons behind response time degradation. By filtering out details like 90th or 95th percentile response times, we gain insight into when and why transactions degrade, providing detailed information.

Some minor issues, like controller crashes and script generation, take time. Sometimes, the code is not generated when we record the scripts in the backend. After clearing the cache, the solution sorts out issues, like identifying the root cause.

LoadRunner integrates with specific tools seamlessly. We do have plans to integrate with Dynatrace or Splunk.

I have been using OpenText LoadRunner Enterprise for 7 to 8 years.

The product is stable. There is no downtime, but sometimes some scripts get corrupted, and the script code generation takes time. There have been environmental or data machine issues.

We have three different instances of LoadRunne. If we're using 1000 users in one of the environments, we use the same hardware for the other environments.

We have one standard license key for all users. 10-15 people have access to this solution.

Customer support is good. We get support for whatever issues we have raised.

The initial setup is easy because I have already spent seven to eight years.

First of all, we need a license key. Then, we need to download the LoadRunner Enterprise software. We require specific specifications. The machines should have a minimum amount of RAM and CPU. We need to fulfil three requests before we can download the LoadRunner file. The installation usually takes around three to four hours.

We have a separate team for support. For example, if we require more CPU, RAM, or drive size on an IBM machine, we seek support from them. However, one person is sufficient for the installation and setup process.

There is another team responsible for maintenance.

Overall, I rate the solution an eight out of ten.

My team does not use it, but we have other teams that use LoadRunner Enterprise. 

We are an SI, and we have a team that does automated testing. They use LoadRunner Enterprise and similar products, and I am continually looking for ways to improve the start-to-delivery time of changes, upgrades, and releases. We have a content server, and automated testing is up there. I have got Selenium. I have got LoadRunner Enterprise to do the automated testing of the active CI/CD pipeline. Now that LoadRunner is an OpenText product, it will make it easier for us to say that our product of choice is going to be LoadRunner. We can drop it in, and off we go and configure it, and then, hopefully, with the link that we have got, we will get this understanding of content suite, Documentum, and digital asset management, and we will get personalized and more appropriate usage profiles and starting points that we would not get if we were using JMeter or Selenium. We would not have to teach this tool about the OpenText stack.

We just finished the upgrade from one version of the code source to another. We have a whole pile of custom code from other vendors, other third parties, and OpenText as well. Doing any upgrades requires a huge amount of retesting. We have to do functional testing and regression testing. Some of that is being done manually, and some of it is being done through automated scripts. We are looking to try and pull that together so that we can get a faster turnaround time. We can also get more test coverage and get it right. We have a three-month window to get a release out, and we can only do a certain amount of manual testing with people sitting there. With the automated solutions, we can leverage a lot more power to push through and get things done, and that gives me the confidence that it works.

We implemented LoadRunner Enterprise for test coverage. With manual testing or other tools, there are only so many tests that we can run in a given time window. There are only so many tests we can do by manually sitting there and without throwing thousands of people out to testing and having consistent results coming back. When we do an upgrade, there is not just functional testing but also things like load testing and performance testing. We are rolling out Azure Information Protection in the next couple of months. One of the things we have to answer before it goes live is if we turn it on and run it in the way our business works, what is the impact when it comes to user concurrency and user profiles? Is it going to work or is it going to collapse under its own weight? Are they going to notice? What is the operational impact? What is the impact that they needed? Is it an extra ten milliseconds or an extra two minutes to upload a document? Being able to model all that and have controlled evidence available for all the different tests is helpful. 

With LoadRunner now being a part of the OpenText family, there is knowledge sharing between the sibling applications. It means that LoadRunner is better positioned or should be better positioned to pick up their other solutions and support them, and we do not have to start from scratch.

We have various customers who use our solutions. Every time we roll out a new integration, change, or upgrade, there are always SLAs. There are always user expectations for how long things take. There is always bug hunting going on in regression testing and making sure that we have not broken anything. Being able to automate those kinds of tests along with the load and performance testing helps reduce the complexity and risk of those activities to the business. With a complex system, there is a risk that we change something over here, and the butterfly flaps its wings, and we end up with something broken over there. We do not see it because we are looking at that new bit over here, and by having a regression test, we can just get a certain percentage done, but with an automated tool, we come across the entire piece. We can identify a suspect and have a look at it. We can see that if we do this combination of data and this combination of settings or users, it works, and then we change this, and it now does not work. We can then fix it. As we roll out new features and functionalities, we can do performance testing. We can do load testing, and we can make sure that for these new features and functionalities, we are ready with the infrastructure to support them. If we roll it out today, and it struggles, then I know in advance that I can put more infrastructure in so that when we turn it on, things work. I can also take it year by year and slot by slot and compare the data and say that my performance metrics were within this, and they have changed. If it comes up towards the SLA or towards the kind of points where the users begin to spot it, I can take action and ask for some extra storage space. If we have 10 gigs a month and a 100 gigs drive, by month eight, we need to order some more space. We do not want to find out two weeks before we get into the tenth month. By being able to see those trends, graphs, and response times for SLAs, but also for general performance and overviews, we can begin to make sure that everyone is heading in the right direction. 

For me, having a wider test coverage—not just functional testing but performance and load testing—means that I have less to worry about because I have more coverage. I can have five guys for a week pressing buttons, or I can have LoadRunner do a regression test suite of x thousand cases in the same amount of time. For coverage, it is a much more useful tool. It has a history. It is great. It is not a new product that OpenText just built themselves. They have got an industry-leading group of people who really understand things, so it is a great addition.

I do not personally use LoadRunner Developer. All the test automation is done by my test automation team. It is very important for me to be able to turn around changes for customer numbers and have things out there. When I started with the OpenText Stack, they were doing one release every two or three years, whereas now, they are doing quarterly releases. When you have got heavily customized systems, or you have got quarterly releases, and you have got all these integrations with SharePoint, SuccessFactors, Salesforce, and other types of applications, the number of things that you have to certify and accredit for testing every time you live is overall a much bigger headache in the connected world. There is just the nuance of all the different variants, data models, and business cases and scenarios that you see, so it is becoming massively unattainable to do that. Having a tool like LoadRunner to do that for you and additionally, having it as a part of the family is valuable. They are on the inside, and they have deep integrations or deep access to all the other OpenText lines of business groups and vice versa. Both sides are going to benefit and grow from that close integration. It just allows me to be able to say that I can shift left because I have the confidence that automated testing has done all my use cases. I have got my performance data. I have got my load data, and I am more within SLA. Trying to do that manually or with some other tools takes a lot longer to get to that, and we do not always get the complete coverage that we want. There is always some risk around how many test cases you can manage running in a week versus just running a tool to plow through them.

Most of my test automation guys use the scripting engine and some of the drag-and-drop features depending on what they are doing, such as building the usage profiles and the automation for the things that they want to do. The tool is shortening the amount of time it takes us to build those automated test use cases. We have use cases for adding a document as a user, as a records management user, as an admin, as someone who has sysadmin rights, or as someone whose first language is French. We get all of these little nuances of access and permissions and everything else, and it becomes interesting. Being able to use tools to deliver all that makes life easier for me. 

The more I spend time with these tools, the more I understand not just the technical benefits but also how they benefit the end-user community. I understand how they can be used to deliver business goals rather than just technical metrics and help shape what we do and give a reflective user experience. We get to compare what our users do on that client system, and we can quickly build user profiles for that particular client rather than throwing 200 generic requests. We do not work like that because then you end up with incorrect data, and you make wrong designs.

LoadRunner Enterprise has helped streamline our testing processes. My team is primarily focused on the content management space where we have the cadence of quarterly releases. We have our own custom modules, and there are custom builds that we have done for customers. We are quickly able to do regression testing, performance testing, load testing, and new feature testing. We are able to test all the different permutations of user location and object types. We are able to test different variants such as adding a document and then adding an email here or there. We are able to package that part and run it as a part of our deployment pipeline, which allows us to align more closely with clients. We are not a year or two behind of where they were, which used to be the only way of doing it previously. It also assures us that even though we are going faster, we are actually doing more while going faster. We are not going faster and doing less. We are now getting more value.

LoadRunner Enterprise reduced our workload or made our life easier. They are a pain to set up, but we have to invest the time to set up the profiles for the users in terms of what the users do on the system. Do they add documents? Do they read documents? We have to understand what those profiles look like so that we can replicate what the client would do, but once we get that and we run them, I know that they reflect my client. They are an accurate reflection of what the client does. I know that the regression testing is going through all the historic and new things, and everything works. With the performance or load testing, I know that as I turn on any feature in prod, which is always different from every other environment, it is going to work. It is not going to collapse under its own weight. It is going to be performance within SLA and within expectation for end users without causing too many problems, so it becomes a useful armory to be able to say to the business that this is going to work. We are able to model situations where we turn something on, and it does not work because we do not have enough infrastructure. We turn it off again and put more infrastructure in, and we turn it on again and see if it works. Being able to model all of that and find thresholds or breakpoints or being able to prove that we can get the throughput makes the conversations easier. It makes the journey smoother as we do things.

LoadRunner Enterprise has helped improve our product quality.

For me, the test coverage and the performance and load testing aspects are valuable. I have a test management team that works for me. They are the guys who are writing JMeter and Selenium scripts and custom labs to do all the testing. I do not get overly involved in that. My role is more about whether the overall solution is going to work. Is the overall platform going to work? Are we within SLA? Are we within functionality? Also, when we do any upgrades or releases, I have to certify to the client. I need to know how many scripts we have run. If we have done only fifty because we only got two weeks, I need them to do more. Having automated testing that we can run and have it consistent every time, and that can run quicker and more efficiently is very important. I get that level of performance, load, and regression functional testing that makes it easier for me to sleep at night.

After they get over the acquisition, the first improvement is going to be tailoring it for their existing stack of other products. How would LoadRunner work for Documentum? How would it work for Business Network? How would it work for other apps? They can have a pre-package or a guide because they are all in the same family as opposed to being outside. When I spoke to the LoadRunner guys, I said, "You are not a part of the family. You have a simple content server test pack, and you have some accelerators that will get me going with your LoadRunner on another OpenText product." They said, "We just started building those because we have just formally become part of the family." That is going to come out. That is going to add value as I roll out LoadRunner and put it on the mix for other customers and new prospects. When those accelerators are there, I would trust them more. I trusted it previously when they were outside or not inside the box. Now that they are both inside the box, I am expecting synergy to be there.

It is a stable product, but there are always going to be things when you introduce something, when you find a curveball that causes a problem, or when you bump into something that does not work. We just flag it up to them. Most of my guys have been around a while with various of these products, so we are able to dig in and help or support the investigation process that the support guys are doing from outside and feed that information into the support process, the R&D bug-fixing process, or the new feature request process. The guys are getting as much help as they can from us. At the end of the day, the more my guys can do to help out the OpenText guys, the better product or support we get. We get a quicker response, so we are helping OpenText support to help them help us.

Generally, if I say that something does not work and I have an error, I get an email asking for logs. I send the logs, and then they ask whether I did that as a sysadmin or as a normal user. A couple of days go by in me checking that, and it goes back in. After that, they ask about the version of patches that we are running. These are the common things that we get asked, so now, we just tick those boxes when we hand it over to OpenText support on day one so that we do not have this kind of delay in the process. We also keep looking at it because OpenText might get something working, or they might not be able to see anything with it because we might have a customized solution or we might be a slightly different version or something like that. The more we can help them and feed it back, the more information they have to zero in on where that problem is. They can come back and say that the last little bit we gave them got them on the spot, and they have now found the bug, and they can fix it. We will get that in this release, and they can hotfix it back for us. Their help is great. I am an engineer, so I always want more documentation, more support articles, and more architecture models so that I can understand more about the solution. It is good to see some of that stuff coming out as being able to be leveraged.

The products do scale. We have some very big customers. Where we begin to struggle with scalability is generally not within the OpenText purview. The bottlenecks we see when we do large bits of work are in the database or in the network because we are just trying to throw some new requests. It does scale, but we just have to scale sensibly rather than just throw more infrastructure at it. Sometimes, you are not solving the right problem. For example, if a customer wants to create three million business workspaces in six months, I ask them how many they need on day one, or which ones would they work with on day one. We load that set first. We then ask them which is their last set, and they say that they have records for people who are no longer account holders, so they want them available, but their account execs and phone guys are not going to be looking at those on day one, day ten, or day twenty. We then move them last, so we break the problem down, and then we look at the tooling that is there. The good thing and also the bad thing is that there is always more than one way to solve a problem. There are tools. There are REST APIs, and there are prebuilt solutions. We need to work out exactly which is the right approach and the right tool to do it. This is where people at OpenText and other customers come in because you can just ask the question about what you want to do. If someone has done it before, they can give you some input to try this or that or look out for this because they bumped into this. You get that kind of community help and support. You certainly get help from OpenText support as well. 

They are very good when you get the right team and the right person. When I started out, there were one or two products. The first line generally had a good understanding of those one or two products, so you get a lot of things answered straight away, whereas now, sometimes, it takes a while because the first-line guys ask you if you are a Documentum guy, and then they have to get the information to pass on to the right person. Therefore, sometimes it takes a while, but once we find the right person, the support has always been great. They are helpful and supportive.

We use a mixture of products based on industry-leading products and also based on our clients' preferred tool. We are an SI, and we do a lot of work with clients. Client X might say that they are a JMeter shop, and this is what we should use because getting anything else accredited requires a separate process. The next client used LoadRunner or Selenium, so we tend to be testing-technology agnostic. However, now that it is a part of the OpenText family, if I have a say in the matter and if they are on an OpenText program, I can say to clients that it makes more sense to go for LoadRunner. I want to pick the product from the same family rather than picking something that is on the outside looking in and does not have that kind of synergy. 

We have seen an ROI. For me and my teams, using automated testing tools from whichever vendor is saving us time and money and improving quality. It allows us to do all the regression testing and get performance data, which makes us able to spot bottlenecks and problems in what we are rolling out. We can see that something works at this scale, but when we try and scale it up, we start seeing issues or bottlenecks that we have to fix before we give it to a customer.

I do not deal with pricing and licensing. My job is to make the engineering work. 

I would rate LoadRunner Enterprise a ten out of ten. It is a product that I have known as being a market-leading tool in that space for years. Being more of a software engineer and architect, testing tools are not something that I am intimately familiar with, but everything I am hearing from the guys that do that work is that it is the tool to use. It is great to have it in the OpenText family.

We are using the solution for performance/load/stress testing of in-house business applications. We have various environments like web applications, cloud-based, SAP, and ERP products. Loadrunner will be used based on end-user requirements.

The main purpose of usage of this tool is to validate the performance of newly developed applications before they are deployed on production. This tool will help us to mimic end-user actions and measure response times from various locations in addition to checking the maximum concurrency supported.

The tools help us to validate the scalability of applications and the limitations of the end-user apps. The main purpose of usage of this tool is to validate the performance of newly developed applications before they are deployed on production. This tool will help us to mimic end-user actions and measure response times from various locations in addition to checking the maximum concurrency supported.

We have used this tool on multiple applications to measure the performance of the system under test. Loadrunner became our enterprise solution for performance testing.

The host performance testing of any application using a host/controller is the most valuable feature. This feature helps to replicate virtual users, configure multiple test scripts, and configure multiple simulators from various geographic locations to run a single test. There are a lot of configurations available to replicate browser cache/with no browser cache and network-related features prior to triggering any test.

The beauty of the host is that any tester can launch it and check the status of runs, monitor test statistics, etc.

The last few years I haven't seen the need for any improvements to the tool other than fancy stuff or maybe moving from client-server to PC or LoadRunner enterprise. There are a lot of tools in the market nowadays where you don't need to spend much time on scripting. Focus on improving the scripless capabilities.

There is not much value added when upgrading/migrating from older versions to newer versions. OpenText should focus on important features and make end-users like us go for Loadrunner/OpenText products as soon as they are in the market. 

We have been using the tool for the last 10+ years.

We did not previously use a different solution.

OpenText/Microfocus productions are costly. They need to focus on minimizing the cost.

We did not evaluate other options. 

We use it for doing automation testing, and there are various teams that use it for performance testing, load testing, etc. For ALM, we use it to create requirements, test labs, and test plans and get our test results in.

LoadRunner Enterprise has helped our organization in being able to document everything and maintain the history. This way, in the future, if the product gets enhanced or new features get added, you know what was tested previously, and then you also have the new stuff. You have the history of those changes and all the testing that has been done.

We use the TruClient feature for browser-based testing, but I am not the end user for it. My guess is that it is helpful for reducing scripting work.

LoadRunner Enterprise has affected our users. Testing is obviously a must before you release a software product. The fact that you can automate some of the testing, and you can do stress testing, performance testing, and simulate a load as if users are actually using it helps a lot. You better understand how the application will operate when it gets into production, and if there are issues, you can spot those early on.

LoadRunner Enterprise has helped streamline our testing processes. We have a process in place for users who need access to it. There is a governance team for the rules and how the product should be used and not. There is a little bit more structure. Based on what I have heard in the organization, it does appear to help them. LoadRunner Enterprise makes it easier for them to be able to do their tasks. They can automate things without them having to manually do it.

LoadRunner Enterprise has helped save us time, but I do not have the metrics.

LoadRunner Enterprise has helped improve our product quality. We can spot issues early on. That helps a lot. This way, we are aware of the issue before we go live in production. We can remediate it before the product goes live.

With ALM, being able to write our test scripts and being able to document our test results are valuable. That comes in handy. This way, we have a record of the things that have been tested. There are also workflows that we can create, which are very helpful. 

With LoadRunner Enterprise, doing various types of performance testing, load testing, and automation testing has been very helpful for some of the teams.

I work more on the administration side. I am not a daily user, but especially during this conference, we are seeing that everything is going to the cloud. We are trying to see what are some of the benefits of going to the cloud.

I have seen some users report some issues, but I have personally not had any issues.

My organization was already using it when I joined, but I have personally been using it for over three years.

I have not seen any stability issues. I have seen some users report some issues, but we will usually open a case if we cannot figure it out.

With LoadRunner, you get load generators. You can add more as needed. Its scalability is fine.

We get our support through another vendor.

When I joined the team, they were already using it, so I do not know what they were using before.

I have been involved in the upgrades. If it is a patch or something small, it is less time-consuming, but if it is a major upgrade, it takes more time and more planning. We need to assess how long it will take, what resources are needed, and do we need to request new servers.

My guess would be that we have seen an ROI.

Overall, I would rate LoadRunner Enterprise a nine out of ten.

We do have an address to the client protocol we are using, and web streaming and web services. 

With LoadRunner, 80% of the cases will be supported. It has everything. It supports most features. It's very feature-rich.

The solution offers helpful guidelines and has good documentation.

While they keep on working on improving the tool level, the tool has instability in terms of loading and processing. There are a lot of times hanging issues up until version 11 or 11.2. After that, the productions are pretty stable. 

They changed the GUI. They had wanted to change the GUI to improve the look and feel. However, since that time, we see a lot of hanging issues.

The implementation process can be a bit complex. Even with 15 years of experience, I have trouble finding things. 

They need to make scalability functionality better.

We've raised hundreds of bugs in the Ajax TruClient protocol. I don't know how they are doing testing. However, they should test it in other scenarios. When you're releasing a protocol, the test coverage should be more. They need to do a better job at releasing a full product instead of releasing something half-done and fixing it along the way.

The solution is expensive. 

I've been using the solution for ten years. 

The solution does have some instability and hanging issues. It has to be improved as it is causing a business loss for them.

Scalability-wise, it has to improve in certain protocols. If you take Ajax TruClient, the memory consumption was very huge in the terms of the particular protocol. That needs to be somewhere where we can minimize the memory consumption to have more virtual users run on the system. 

People need to buy too many load generators to run their tests. Even for file users, we need a lot of load generators to run that.

We have seven to eight team members using the solution right now. 

We have been using it for the past 10 years with the same client. We have all the version upgrades happening from LoadRunner ALM products onwards. We went into the ALM Enterprise. And we were the people who raised hundreds of bugs in the Ajax TruClient protocol. 

We've dealt with lots of bugs, and we scheduled a meeting for support. They take some time to get to a solution. They'll sometimes take months to get a solution in place.

I understand it is not a small thing when you are launching a new protocol and all. However, they should have, before launching, fewer bugs. They need to take care of a lot of things before launching the product.

We've used JMeter, WebLOAD, and NeoLoad.

While Micro Focus' competition does offer a lot of tools, this solution does a better job of laying out guidelines.  There are examples and use cases, and they respond to questions. Those are the reasons people are still using them.

The installation process is a little complex. There has been confusion in terms of the Enterprise version and whatever they have in the exhibition suite. We call it ALM. The UI is not as user-friendly now with the changes they have made. It would help if they simplified their interface a bit. It might make implementation easier. 

It used to be simpler. Now we have a separate team that handles the setup.

We have two people available that can deploy and maintain the product.

We don't see an ROI as we mainly recommend the tool and clients use it.

It's a costly tool. When you are paying for something, there are expectations that it will work properly.

I'd rate the affordability at a two out of five. 

You do need to buy a few extra features that are not included in the main cost.

We are customers.

If a client has a budget, I would recommend the solution. It is a good tool. However, there are stability issues, and it does have a complex UI. It's good if you have specific protocols and specific requirements. When that is the case, there may be no other tool available. 

I'd rate the solution seven out of ten.

We use LRE to develop script and we use VuGen, a component of LoadRunner, for result analysis. Those two components are responsible for generating load and then injecting it into a particular system. We develop the script on VuGen, and create a smooth scenario on LRE that uses a load generator and controller to run the test. The controller then collects the results and we carry out an analysis. We are customers of Micro Focus.

Creating the script is very easy and user friendly. If you need to simulate a use case, it's easily recorded using VuGen. It also enables the creation of monitors for a particular system which includes FD dashboards. Remote servers can also be monitored while your test is running on the LRE dashboard.

I'd like to be able to carry out transaction comparisons with previous tests. It's a feature of NetStorm that I'd like to see in LRE. Currently, we can only compare averages to transition response time. Having that ability to compare would highlight any patterns, comparing them with results at regular intervals. We'd be able to know what was going on throughout the testing process. 

Some of the scripts we use require some custom JARS. It requires importing something to the script if those have been embedded. If that process could be automated, it would make a difference. Whether it's MQ, Kafka or JDBC, those kinds of binaries could be part of a bundle. 

I've been using this solution for two years.

We had some initial issues that were resolved and since then the stability has been good. 

We haven't used their scalability capabilities yet, but I'm sure it's good.

Their technical support is excellent.

Positive

The initial setup was carried out before I began working in the company but I believe it's very straightforward. We have 70 performance engineers using this solution in my team. 

We are an enterprise company so we have a license with Micro Focus. I believe that if you have up to 50 users, there is an open-source option. 

I would recommend downloading the software for personal use to test it out. The solution solves my needs and provides everything required to carry out performance load testing so I rate the solution nine out of 10. 

We employed OpenText LoadRunner Enterprise for a diverse range of applications and objectives. Since we are in the healthcare industry, this solution helps us to manage the digitalization of the data and ensure successful end-to-end workflow.

It delivers multiple benefits across various aspects. We can efficiently monitor all of the system resources and network usage. It also helps us to identify performance bottlenecks, and optimize application performance.

The most beneficial features of the solution are flexibility and versatility in their performance. It is seamlessly handling a wide range of protocols and technologies.

Offering a direct integration feature would ensure a completely smooth experience. Until now, we had to use different tools running in the back to get a perfectly detailed analysis.

We have been using the solution for a couple of years. 

The stability is at a very high level. I would rate it nine out of ten.

If we put aside the licensing challenges, OpenText LoadRunner Enterprise can stimulate numerous virtual users, making it suitable for testing large-scale systems. I would rate the scalability eight out of ten.

We didn't have many situations that required us to request assistance, but when we faced certain minor issues, they provided excellent support.

Positive

We used to utilize Apache JMeter, and it is a good solution, but OpenText LoadRunner Enterprise offers better features that are suitable for our business. Its flexibility in terms of building a CI/CD pipeline across the platforms is a benefit.

The initial setup process is straightforward for a simple type of server architecture. But if you are integrating separate test generator engines between the setups, it will require support from the supplier. It is important to have a strong understanding of performance-testing concepts. 

The suitability of the solution depends on the specific needs and requirements of an organization or project. It also depends on which model will be integrated and used, as does the price structure and the licensing. We are content with the pricing and find it to be reasonable in terms of value for money. The only challenge is when it comes to large enterprise companies that are working with multiple suppliers. The integration of licenses is very difficult or in some cases, impossible.

OpenText LoadRunner is the leading solution as of now. There are definitely other tooling options available in the market, but if you are searching for an enterprise-level solution, LoadRunner is the number one product.

Overall, we are pleased with the solution as it satisfies our requirements and meets our expectations. I would rate it eight out of ten.

Our organization uses the solution for testing the performance of applications mainly. At times, we have also used the services provided by the solution, like network virtualization and service virtualization.

The type of application support Micro Focus LoadRunner Enterprise has is very good. The solution does support a wide range of technologies and protocols. Plus, two features, network virtualization, and service virtualization, are really helpful. Apart from that, the way they have their billing scenarios, like the execution, is very good. We can also have a lot of flexibility in building various scenarios or a load test which is one good thing. I like the way they have made their reporting area. Using certain features in the solution, the insights one gets are very useful for understanding the performance issues in the application.

Some areas for improvement in the solution are mainly based on the fact that right now, in the market, there are emerging low-code or no-code platforms, like NeoLoad. In Micro Focus LoadRunner Enterprise, we have to work on scripting. So, I need a skillful resource if I want to hire anyone. In the case of NeoLoad, a low-code environment, and platform, I don't have to search for a skilled resource. I can provide cross-skill training to the existing workforce, and they can work for me. In Micro Focus LoadRunner Enterprise, I need to spend a lot of time training people, while on other low-code or no-code platforms, I need not invest that much time.

I have been using Micro Focus LoadRunner Enterprise for ten to twelve years. Also, I am using the solution's latest version. My company is just a customer of the solution.

It is a stable solution.

It takes time to build skills around Micro Focus LoadRunner Enterprise. Also, a person who knows LoadRunner can work on any other tool since that person will know the basic concept of performance testing. There are a lot of users in my company who are using the solution, and if I were to give a count of the users, then it would be in the thousands. Presently, there is an increase in the usage of the solution and the number of users using the solution. Also, I don't have an idea of how the solution is being used by other teams which operate in other countries.

The solution has a good customer service and support team. I have dealt with them multiple times in the past, and they do support us wherever required. I rate the technical support team eight or nine out of ten. To be more concrete, I would rate them a nine.

Positive

The solution's initial setup process was straightforward.

The solution was deployed on the cloud.

The solution has all the capabilities. The only area they need to work on is the low-code platform which has started emerging in the market lately. If they could do something in that area, it would be a great overall tool in the market. Right now, it takes a lot of time for me to train people and get them onboarded. However, while I use other tools like NeoLoad, I can easily train my team.

I rate the overall solution an eight out of ten.

Micro Focus LoadRunner Enterprise scripting tool. We run scripts using this tool. The performance center is where we do the simulations and testing based on whatever application the organization that I work for uses.

The most valuable aspect of Micro Focus LoadRunner Enterprise is the overall support it has for a lot of different applications and defined domains.

The price of this solution could be less expensive. However, this category of solutions is expensive.

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

Micro Focus LoadRunner Enterprise is stable. We are in the process of upgrading to the newer version, but the version we are using supports many applications, such as web and Java-based applications.

Micro Focus LoadRunner Enterprise is scalable.

We have three people using this solution in my organization.

I have previously used JMeter.

We install Micro Focus LoadRunner Enterprise in our local systems.

We did the installation of the solution with our system administrators or a manager who has access. Not everyone has the correct access to install the software.

This solution can be expensive.

One person is enough for the maintenance of the solution when we have three people using it.

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

We had to move applications from a mainframe environment to a targeted new environment. We needed to conduct load and stress testing as part of the process. We also used it to keep track of the test cases in the repository. 

We initially used LoadRunner Enterprise on a project basis. However, it exceeded our expectations, and we bought a small number of licenses. 

Our main use case for the product was load and stress testing. It helped us put the system under stress by injecting in multiple users, such as 5,000 users. 

OpenText LoadRunner Enterprise doesn't support some mainframe protocols. We had to build scripts to access the interface. 

I have been using LoadRunner Enterprise for two years. 

OpenText LoadRunner Enterprise is a mature product with high stability. I rate it a nine out of ten. 

We used only about 20 test cases. We didn't push beyond that. 

OpenText's support is good. 

Positive

We got an 80 percent discount for the product. It was cost-effective, but licenses tend to get expensive. 

The main challenge we resolved using the product is ensuring the functional equivalency of applications that migrated from old to new environments. 

OpenText LoadRunner Enterprise has streamlined our testing process. It acted as a single source for the test cases and criteria. We could pull reports and show the management that the system is tested and can be taken live. 

The solution has helped us save time. 

Before OpenText LoadRunner Enterprise, a customer did not have a repository of test cases. Hence, they needed to redevelop the previously used test cases. However, the solution helps to reuse test cases. 

I rate the product an eight out of ten.