OpenText Enterprise Performance Engineering (LoadRunner Enterprise) Reviews

My use case for OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is related to enterprise twenty six, which we are going to upgrade now. We focus on web applications.

I find OpenText Enterprise Performance Engineering (LoadRunner Enterprise) to be user-friendly first. The second thing is a wide variety of user types, such as the number of protocols supported. The third one is the single working station for controlling the generator. The fourth one is the crypts readability and extendability.

OpenText Enterprise Performance Engineering (LoadRunner Enterprise) helps us to identify the hotspots from the applications during peak times through the LRE simulation. It is helping us with the performance part of the application.

Regarding points for improvement for OpenText Enterprise Performance Engineering (LoadRunner Enterprise), I see that features are not being fully developed yet. If OpenText could think about bringing AI features into the tool, it could save maximum time in scripting or make scripting effortless, particularly in correlation, which is where the complexity involved in script development exists. If any AI features could replace or eliminate more manual work on the correlation part, that is where we could see a game-changing improvement for the tool. OpenText Enterprise Performance Engineering (LoadRunner Enterprise) can be positioned very well in the market. However, I see that the basic correlations are only being handled by the autocorrelation engine in the LoadRunner tool, and I would expect a few improvements to handle even complex correlation problems so that the tool can be appropriately positioned compared to their peers.

I have been working with OpenText Enterprise Performance Engineering (LoadRunner Enterprise) for a pretty long time, approximately twenty years.

From a stability point of view for OpenText Enterprise Performance Engineering (LoadRunner Enterprise), I would rate it as seven based on the version that we are using.

The ability to scale and expand with OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is a six. It is simple to scale.

Regarding OpenText technical support, I find it very pathetic. I do not understand how they are going to expand this from the technical support point of view. BlazeMeter, compared to LoadRunner, is still scalable and expandable easily. It is also hassle-friendly to integrate any test scripts into BlazeMeter. The third point is that tech support is fabulous.

The initial setup for OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is not simple. To set up LRE in the corporate firewall system, it is complicated. That simplification has to happen. We are expecting that the simplification of the infrastructure setup should be done quickly and should not depend on the vendor. It should be a self-substantive platform that allows us to deploy ourselves without depending on the vendor, avoiding much team support.

In my opinion, the key competitor for OpenText Enterprise Performance Engineering (LoadRunner Enterprise) on the market is BlazeMeter.

If I compare OpenText Enterprise Performance Engineering (LoadRunner Enterprise) and BlazeMeter, I find BlazeMeter to be better for me. The rating for scalability, expandability, and extendability from my point of view is six and seven for OpenText Enterprise Performance Engineering (LoadRunner Enterprise), but BlazeMeter is far better in the comparison for web applications performance testing. BlazeMeter is still easy to integrate JMeter scripts that can be invoked through the public cloud machine. The customer support for BlazeMeter is very, very fast. The moment you try the ticket, you get a response back in no time from the vendor. The vendor support is fabulous in BlazeMeter compared to OpenText Enterprise Performance Engineering (LoadRunner Enterprise).

As for the distributed testing feature of OpenText Enterprise Performance Engineering (LoadRunner Enterprise), I am not using it currently. It is the enterprise version. We are already subscribing to load on our enterprise version of twenty six, but in the future, we will be sticking to this performance center version of the load on our enterprise load runner enterprise edition with the distribution load generator functionality.

Regarding the analytics and reporting part of OpenText Enterprise Performance Engineering (LoadRunner Enterprise), we do not use reporting extensively from our side. However, some of the features are quite interesting and easy to interpret with the application metrics. Analytics is fine. The page meter is similar. Features are already providing and slowly maximum rate is replacing load on our features from BlazeMeter. We are using both LoadRunner and BlazeMeter. It depends upon the application configuration and the environment dependencies.

The key benefits I get from OpenText Enterprise Performance Engineering (LoadRunner Enterprise) are that nothing majorly is helping, but it is part of the development life cycle. We have to use some load, stress, volume, spike, and endurance methodologies to be simulated. It helps us to establish the metrics within the corporate firewall system.

My overall rating for OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is six.

I use OpenText Enterprise Performance Engineering (LoadRunner Enterprise) for testing the performance of systems with APIs in the banking sector.

I appreciate the visual design in Enterprise very much, as it is very beautiful. There are many features in the servers where I manage other servers as well for my injectors. I have extensive control over the results and logs, with significant control over servers and injectors. I can create scenarios either manually or automatically.

I have one concern in that my server for OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is located in another country, and there is some latency when I control tests. However, this is not a negative aspect of OpenText Enterprise Performance Engineering (LoadRunner Enterprise) itself, but rather a limitation of my infrastructure.

Regarding the features for different versions of OpenText Enterprise Performance Engineering (LoadRunner Enterprise), it is not clear to me which features are correct for my Windows server or whether the functionality is appropriate for my infrastructure. Many aspects, such as logging, do not align correctly with my needs.

I have used OpenText Enterprise Performance Engineering (LoadRunner Enterprise) for two years.

OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is very stable.

OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is very scalable.

I have contacted support for OpenText Enterprise Performance Engineering (LoadRunner Enterprise) on one occasion. The support was for sales of OpenText Enterprise Performance Engineering (LoadRunner Enterprise). The sales support is very good.

On a scale of 1 to 10 for the support of OpenText Enterprise Performance Engineering (LoadRunner Enterprise), I would rate it a 10. The sales support is very good, though this was my only opportunity to contact them.

I have previously used the alternative JMeter before OpenText Enterprise Performance Engineering (LoadRunner Enterprise), but my company cannot use it.

The initial installation of OpenText Enterprise Performance Engineering (LoadRunner Enterprise) was difficult. I faced many difficulties in understanding which versions to use or which buttons I needed to configure for my injectors in the servers. It took me six months to understand OpenText Enterprise Performance Engineering (LoadRunner Enterprise).

OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is very expensive. Compared to JMeter, it is very costly.

For me, OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is the solution. JMeter is similar in protocols, particularly for MQ.

I use the Cloud version and the Enterprise version of OpenText Enterprise Performance Engineering (LoadRunner Enterprise). I updated my understanding of OpenText Enterprise Performance Engineering (LoadRunner Enterprise) and considered the language C for it. I do not use other versions of OpenText Enterprise Performance Engineering (LoadRunner Enterprise), only the current version. The setup is automatic for OpenText Enterprise Performance Engineering (LoadRunner Enterprise). I would tell anyone researching OpenText Enterprise Performance Engineering (LoadRunner Enterprise) on PeerSpot that I rate it a 10 for everything. It is very good.

I always consider the purposes and use cases from an enterprise version perspective as a user of the product.

The advantages of OpenText Enterprise Performance Engineering (LoadRunner Enterprise) are clear. The analytics and reporting features provide beneficial impacts on my organization. The scalable testing environment is very beneficial for my performance testing processes.

Scalability is a main important factor when identifying bottlenecks. For example, when I target about 100 users but scale up the system to 120 or 150 users, I can identify where the bottleneck starts to occur.

Regarding negative sides or areas for improvement, I do not see any disadvantages so far. OpenText Enterprise Performance Engineering (LoadRunner Enterprise) might have some drawbacks, but I did not go to that extent to find any. Regarding new features they could add, I am not getting anything at this time.

I have been using OpenText Enterprise Performance Engineering (LoadRunner Enterprise) for two years.

In terms of stability, I would give a rating of nine. The product is stable.

For technical support, I would give a rating of eight. Although technical support issues are not directly related to OpenText Enterprise Performance Engineering (LoadRunner Enterprise) but related to partners, I need to contact support through them since the partners are in between. The technical support experience is a bit limited due to this indirect relationship.

Positive

When discussing price, OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is very expensive, which I would represent by a rating of ten. The product carries maximum expense points.

I have experience with load distribution testing. Based on the load requirements, I set out the virtual machines and load generator systems according to how many are needed and what capacity they can provide. That dependency is based on the load.

Regarding marketplace specifics like AWS or Azure, I am uncertain whether that applies to AWS Marketplace or Azure Marketplace.

For my project handling, I use JMeter for approximately 90 percent of the projects I manage and OpenText Enterprise Performance Engineering (LoadRunner Enterprise) for 10 percent of my projects. My overall review rating for OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is nine.

The typical use case for OpenText Enterprise Performance Engineering (LoadRunner Enterprise) involves ensuring performance before go-live or ensuring performance after upgrades, or sometimes big data center migrations and big platform changes.

The best features of this solution are easy scripting and broad platform support.

The distributed testing feature of OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is also a fantastic feature.

The analytics and reporting features can be improved, though they are good enough. If you have expertise, you can manage with what is included. However, it could be much better, especially with modern AI capabilities.

When considering areas for improvement in OpenText Enterprise Performance Engineering (LoadRunner Enterprise), there is a need for automated analysis and code-level support.

I have experience working with OpenText Enterprise Performance Engineering (LoadRunner Enterprise) since the early 2000s when it was Mercury.

Regarding stability, I would rate it an eight or nine. From time to time, we encounter bugs that are unexpected from a 20-plus years old solution. However, it remains quite stable.

OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is a scalable solution.

I rate the scalability of OpenText Enterprise Performance Engineering (LoadRunner Enterprise) as ten when using a scale from one to ten, with one being low.

The customer service and technical support for OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is reasonable, not impressive, but provides adequate assistance.

Positive

The initial setup of OpenText Enterprise Performance Engineering (LoadRunner Enterprise) is straightforward in terms of adaptability.

I have seen an ROI from this tool, as it provides enormous value. It ensures that you are not setting yourself up for failure. It functions as an insurance.

The price of OpenText Enterprise Performance Engineering (LoadRunner Enterprise), including pricing, licensing, and setup cost, is reasonable. It is neither cheap nor expensive.

For those looking into using OpenText Enterprise Performance Engineering (LoadRunner Enterprise), my advice is that what they see is what they get. It is a solid performance testing solution. If it works, it works. If it does not work, good luck. It is a technical solution for most platforms.

On a scale of one to ten, I rate OpenText Enterprise Performance Engineering (LoadRunner Enterprise) an eight.

I use it for performance testing from top to bottom at every level possible. For functional user interface performance testing, API performance testing, with all types of tests like load, stress, performance, capacity planning, anything that you might qualify for testing. 

I use it in various domains, in government institutions, in banking, in retail. Actually, my last projects were for government institutions, one on banking recently, and on retail, it worked quite a while ago, but in 2003. So, or some as well.

I use UFT for functional testing in your API testing workflows.

I work with LoadRunner in a distributed environment. 

It performs very well. I have no problem with it. LoadRunner has one major advantage compared to all other tools I know from the market. It's old enough and can test almost every tool in the companies I enter. It supports between 35 and 60 different software applications which need to be tested. 

With LoadRunner, I have one tool that can test everything. If I'm using, for example, JMeter, JMeter can test only web-based APIs and some limited user interfaces, and then I have to use another tool for the others. 

So, this is the main advantage, and this is why I choose to work with LoadRunner. It's not a perfect tool, but it does the job in terms of distributed applications with different technologies in the corporate environment.

Moreover, the integration capabilities are impressive, especially with Dynatrace. It was a significant advantage last week to harvest information directly from Dynatrace, a monitoring system. Previously, when LoadRunner was associated with HP or Microsoft, there was a push to bundle LoadRunner with their monitoring tools. 

If you didn't purchase LoadRunner alongside their monitoring solutions, managing separate logs became a necessity. However, now that LoadRunner integrates with Dynatrace and other monitoring tools, it simplifies the process of integration into a company, taking merely five minutes to set up. 

This ease of integration allows for quick comparison of monitoring and performance results, a feature I highly appreciate.

I find the runtime settings beneficial for creating realistic load scenarios, which allow me to combine different actions into realistic workload scenarios. So, runtime settings and the features in there.

The real-time test analysis and reporting feature has very much enhanced the testing processes for me. In terms of reporting, I have a controller that must be used all the time to make the most out of that license. So, basically, the server that has the controller installed is used window after window of testing. 

I use it for two hours, another colleague's test for two hours, etc. Now, if my test lasts exactly one hour and a half or two hours, I do not have the necessary time to analyze the results on the server. 

So I take it offline on my computer, where I have the Analyzer for free, due to OpenText's license system. And then I can analyze it offline for as much as I want so I can draw my conclusions. 

Features inside the Analyzer that I use are overlapping graphs or correlation of graphs, all these kinds of stuff which allow me to see the results much faster than in other tools.

It would be beneficial if LoadRunner could optimize resource usage, especially for protocols that require significant resources, like TrueClient, which interacts directly with the UI. 

If they could improve resource usage, like ingest or for the load generator, using less CPU or RAM memory, that would be great. That's where I have problems. 

In real time, when they ask for 5,000 or 10,000 concurrent users, I have to provision a lot of virtual machines to define this load.

Then there are situations with certain platforms, especially document management platforms, where the technology is so weird that normal LoadRunner protocols cannot detect it. 

So, in that case, I have to use that special TruClient protocol. I have to use the TruClient protocol, which actually clicks on the object. Despite the SQL technology, I can still create a script and test for performance. 

So what I would appreciate a lot is if this protocol would require less resources on a normal virtual machine. I can use fewer concurrent users with TruClient protocols as opposed to almost one hundred with HTTP/HTML. As opposed to many more with HTTP/HTML from, let's say, JMeter. So, optimization at that level for resource consumption by OpenText would be much appreciated.

I have been using it for many years, since 2003. 

And recently, just yesterday.

I find it stable, there are no issues with its stability.

It's 100% scalable without any problems. 

In terms of usability and volume, everything is satisfactory. However, the licensing cost becomes an issue beyond a certain number of users, as licenses become expensive. 

Pay-per-user licensing limits the tool's use, although scalability and volume handling are otherwise excellent.

My team and I are quite experienced with the tool, which allows us to resolve most issues independently.

We almost don't need technical support. In my team, I have three professionals using LoadRunner, and out of three plus mine, for four people, we can find solutions to even difficult problems. So, I haven't used their support lately.

From the SmartBear tools, we use ReadyAPI. We've been using it for five years, and I've actually been a training partner for IBM for the last three years, delivering training for them using ReadyAPI.

We use it for API testing and service virtualization. I like the interface. It's easy to use. 

Feature-wise, it is the same as other tools on the market. Not something spectacular about it. But usually, it covers all the needs you might have in IT and quality assurance in general.

We also use OpenText LoadRunner Cloud. For API performance testing, I prefer to use LoadRunner.

I've worked with LoadRunner since a long time. I know it much better, it's much more familiar. It's nothing wrong with ReadyAPI. But if I had to choose between the two, I would choose LoadRunner because I have experience with it. It does everything I need, so that's why I work with it.

The setup process is straightforward and easily manageable even by a junior technician.

The installation of LoadRunner takes about an hour, and I can start building scripts on the same day. So, it takes less than a day to deliver something.

I've worked with environments ranging from 10 to 10,000 concurrent users, covering everything in between.

Maintaining LoadRunner itself is not difficult. However, the complexity of maintaining scripts depends on their complexity and the user's scripting skills. So, it is not about the tool, but it is about the user. 

There is an ROI. What LoadRunner does, is it prevents failures when there are many, many concurrent users in the systems of a company. 

For example, what I do is I find in my client's timeline the historical moment where their application crashed, and they actually calculate their own damage. 

Then I come with the performance test, and I take out as many performance bottlenecks as possible. So I tell them, "Look, now it will not crash in production because we have seen this exact situation." And I'm responsible to say for what I'm actually saying. But this is how I prove the value of the tool. 

Another way to prove the value of the tool, even when it's quite expensive in my opinion. But since it can test different applications in the system, I do split the cost of, 30 to 40 projects. And when I split the cost into 40 projects, I will have a return on investment because it becomes a little bit cheaper. It all depends on budgeting and the customer. If I have a customer with an open mind, I can justify the cost. 

If the customer is narrow-minded, then they don't want to use, and they are resistant to change, and they don't want to pay for trained professionals, I rather not sell. 

LoadRunner is easy to use. It's easy to test anything in any big corporation at an enterprise scale. So that's what I appreciate. It is easy to pass the knowledge to newcomers. 

And very heavy resource consumption and expensive. These are the cons.

LoadRunner is user-friendly and adaptable for enterprise-scale testing, with easy knowledge transfer to newcomers. However, its resource consumption and cost are considerable drawbacks.

I recommend it with one remark. Please hire a professional consultant if you don't have in-house resources for the first test. So, with the right consultancy, LoadRunner is a powerful OpenText tool. 

If you don't have the right consultancy, you'll be using it at 10 to 20% maximum, and then it's a waste of money.

Overall, I would rate the solution a ten out of ten. 

We are an e-commerce website. We use it for both website testing as well as API testing. Most of the time, we do API testing, and there is no recording as such. When it comes to UI, we have applications that are pretty rich in Node.js technology and other frontend technologies. There are some specific server-rendered pages as well as client-rendered pages. It is more of recording and then customizing and using it for backend load simulation. For performance testing, the metrics that we capture are mainly based on the frontend. We rely on W3 semantics there.

We predominantly use the Web-HTTP/HTML protocol. We also use it for maintaining our scripts, which means storing and making sure that we maintain the scripts in a proper way.

Performance testing is one of the checklist items for us, irrespective of the release or changes done at the backend. We have customer-focused applications in our business. If the customers are not happy with the way they are accessing the application, it impacts our business. That is the reason why performance testing is a must. LoadRunner is playing a very significant role in completing our tasks.

LoadRunner Enterprise has reduced our workload. We are also using JMeter for some of the applications where API testing needs to be done. JMeter requires a lot of customization using Java, but that is not the case with LoadRunner. It definitely makes our work easy.

LoadRunner Enterprise also saves time. For example, for a script in JMeter, I would have to spend four to five hours in JMeter, including the test data setup and then validating multi-user iterations, whereas, with LoadRunner Enterprise, I can complete that in two to three hours. It saves 50% of the time. LoadRunner Enterprise is also better than JMeter in terms of competency or skills. For example, for JMeter, you need to have a knowledge of Java, but that is not the case with LoadRunner Enterprise. It is as easy as understanding any simple script.

LoadRunner Enterprise has been helpful in simulating the load, but not in the analysis as per our needs. If I can have additional features that will help us in performance engineering, and not just in the testing, it would be great. If we are able to analyze and have exact hot spots during the testing itself, we would not have to depend on any of the APM tools. That will definitely add value.

It is pretty easy to do test execution and results analysis. When it comes to scenario settings, LoadRunner Enterprise has an extra edge over other testing tools in the industry. The scenario setup is easy, and in terms of execution, we have a clear idea of what is happening. When it comes to analysis, it is easy to download the analysis file and see all the analysis. We have many filters available, and it is easy to customize according to our needs.

When we have a new application, recording the application is a pretty tough task. We have tried multiple things. We do scripting or try to record with different settings and on different machines. We try to record multiple times, but we do not know why it is recording and why it is not recording. We do the same thing on different machines. It sometimes records, and at other times, it does not. That is one of the major concerns.

Another issue is that while executing the load test, we recently faced an issue related to the mmdrv process. After the test is complete, from the LoadRunner Enterprise perspective, it does not show anything running, whereas, at the backend, we see that the load is getting generated from the load generator. We got to know that it is because of the rogue mmdrv process that is running even after the test is complete. We have raised this issue multiple times. The patches or solutions that they have given are not working. We have raised a ticket for this one as well. 

For each and every release, one of the criteria that we have is that it has to pass performance testing. It does not matter how big or small the changes are. Irrespective of the extent of changes, performance testing is required. We give a lot of value to performance testing. For us, performance testing is not only the test execution. We consider that as only 10% of the end-to-end performance testing. The analysis portion of it is where we want to spend 90% of our time. Our scripting effort is not too much, but it is still considerable. For a given application, if end-to-end testing takes 16 hours, then out of that, we need to spend at least four to five hours on scripting, customization, test data setup, etc. For the rest of the things, we have to spend about 12 hours. LoadRunner Enterprise can provide value by enabling us to do these analysis and performance engineering aspects within the tool. LoadRunner has a new feature in the cloud for single transaction analysis or single-user testing analysis. It shows all the insights in terms of the response and hot spots. If they can expand that to LoadRunner Enterprise as well, and not just to the cloud, it would be helpful. 

One more issue is that some of the features are enabled in certain LoadRunner versions. They are not available in other versions. To get a specific feature, the problem is that I either have to upgrade to a different tool or completely get rid of it and then use another tool. Instead of that, they can enable the features irrespective of the platform. Each and every tool that they are producing has its own advantages as well as improvement areas. For example, LoadRunner Professional has the advantage of using chaos engineering tools, which is not there in LoadRunner Enterprise. Irrespective of the tool version I am using, I should have the same advantage. I would like to see chaos engineering in LoadRunner Enterprise.

Their support should be more efficient. I do not raise a ticket just to see the answers that are already available on the Internet.

It has been five years.

Its stability is fantastic. Out of 100 test executions, there is usually one case when it is not able to capture and generate the analysis file. We then use some manual methods to generate that analysis file and get the results.

Its scalability is fantastic. We have no issues. We can increase the number of load generators, and we can increase the number of tests that we are doing on a day-to-day basis, so everything is good.

They helped us a lot during deployment, but on a day-to-day basis, whenever we have any issues, there is a lot of opportunity to improve. I have also given this feedback to OpenText. I would rate them a five out of ten because there is a lot of room for improvement.

Neutral

I have used solutions from different vendors. One of them is BlazeMeter, and I have also used NeoLoad in my previous organization. 

In my current organization, we are also using JMeter. With JMeter, we have to spend more time in scripting, test data setup, etc. With LoadRunner Enterprise, there is a 50% time reduction. It is reducing 50% of the man hours that we spend in scripting for JMeter. That is an advantage.

We recently upgraded LoadRunner Enterprise from the previous version. It was definitely complex. There was the infrastructure upgrade as well as the licensing upgrade. We also have to have a different set of load generators, controllers, and other things. It was a complete switch, so it took time and was complex.

It offers flexible deployment options, including on-prem, SaaS, and hybrid, which is very important for us. The reason is that we are migrating our applications from on-premises to the cloud. When we test applications in the cloud, one major aspect or component that we need to consider is network utilization. If your load generators are on-premises and you are hitting from on-premises to the applications hosted in the cloud, network bandwidth consumption will come into the picture, and your response time will include that. It is sometimes acceptable in real-case or production scenarios, but it is sometimes not acceptable because the systems that will access the particular service that is under test may or may not be hosted in the cloud itself. In that scenario, I have to have a solution that I can directly hit in the cloud itself. In that case, I would like to have LoadRunner Cloud. At the moment, we are looking at using the Flex model of LoadRunner infrastructure deployment, which means we will have load generators on-premises as well as in the cloud.

We have our own internal team.

We got a very good deal. We are happy with that. We have 5,000 licenses.

We are currently not using LoadRunner Developer, but we are planning to use it. We also do not use the TruClient feature. It has some disadvantages where it requires a lot of hardware capacity, and we are currently not at that level.

Overall, I would rate LoadRunner Enterprise an eight out of ten. We are pretty satisfied with LoadRunner Enterprise, but it would be great if they also added performance engineering capabilities. It meets our current requirements, but there is scope for improvement. In terms of future growth, we are looking for more contributions from the OpenText side.

I have been using LoadRunner for multiple industries. Initially, I used it for the banking domain, then for the insurance domain, and later, I used it in the manufacturing domain. Recently, I employed it in the healthcare domain. Until 2017, I used it for the manufacturing domain.

LoadRunner has allowed me to provide customers with insights into what issues their projects or applications are facing. With LoadRunner, I was able to offer detailed results and insights that helped explain the problems with their projects.

I've used other tools, such as RPT and JMeter. I find LoadRunner very user-friendly. Particularly, the process of creating scripts in LoadRunner's architecture, though not easy, becomes transparent and understandable, aiding in debugging and repairing scripts. Other tools like RPT or JMeter don't provide the same level of insight. 

Furthermore, LoadRunner's UI is project-convenient, allowing easier simulation of real-time scenarios and producing comprehensive reports that are effortless to read. These reports detail the logs and streamline error debugging.

While I don't see any issues with LoadRunner's functionality, the cost of the tool is a major factor. Many of my customers have had to switch to different tools due to the cost of LoadRunner, despite its advantages, leading them to alternatives like JMeter and RPT. 

Additionally, the packaging of the product, where different protocols come with separate plans, is not very convenient compared to other tools where licenses include all protocols.

I have used LoadRunner almost for 12 to 13 years.

LoadRunner is stable.

LoadRunner Enterprise is also very scalable.

I would rate customer service between seven and eight out of ten. Sometimes I received quick answers, while at other times, especially for some issues, I had to follow up extensively to receive satisfactory responses.

Positive

I have used other solutions like RPT and JMeter. Our choice sometimes depends on cost considerations as JMeter is free of cost, making it a first preference for smaller projects, whereas RPT is cheaper than LoadRunner.

The initial setup of LoadRunner is straightforward. I never found any issues while setting it up.

I handled the setup by myself, but it can easily be done by one of my team members.

While I cannot calculate the exact return on investment, LoadRunner has provided more return in comparison to other tools by offering detailed insights into applications which aid in identifying issues.

In 2019, I was dealing with the costs of LoadRunner. While I don't remember the exact figures, JMeter being free and RPT being cheaper makes them attractive. The high cost of LoadRunner, in contrast, often caused customers to switch.

I have evaluated and used solutions like RPT and JMeter.

If it wasn't for the cost, LoadRunner would be my first preference based on my experience using multiple tools for load testing and performance testing.

I'd rate the solution eight out of ten.

It's for performance testing of our front-end UI applications, web service systems, APIs, and for the applications that are developed in-house by our solution developers.

We use it as a standalone performance testing tool, not integrating it with anything else. However, I know other clients may integrate it with tools like ALM, which we haven't done.

LoadRunner Enterprise helps identify bottlenecks in our high-traffic application scenarios. It identifies bottlenecks by monitoring slow response times and exposing errors that might emanate from an application under load. 

It's able to expose these factors to us, allowing us to monitor through LoadRunner and see how the infrastructure is coping during the load test. So, we get a lot of insight into how the application is performing under load.

Moreover, LoadRunner was instrumental in scaling our application for peak load testing. 

There have been situations where we were able to expose some performance degradation, especially in our BI and AIU processes, when a change was implemented to an existing application. We would perform a regression test and sometimes find out that whatever changes had been made actually degraded the application's performance. We were able to expose that and report accordingly for remedial actions to be implemented. 

In terms of scaling up the application, especially for new applications where the business expects it to handle a significant load, we find out through testing if it doesn't meet their requirements. Then, we can advise whether the infrastructure needs to be expanded, scaled out, or up, and we implement solutions accordingly until it meets the requirements.

For me, LoadRunner stands out, especially with its reporting capabilities, the graphs that can be generated, and the unique feature of measuring our application's response alongside our infrastructure metrics, such as CPU, memory, or disk usage, all presented in graph form. This is something other applications struggle to match.

The real-time monitoring and analysis feature improved our test accuracy. It significantly enhances test accuracy by providing a holistic view of the testing process. Real-time monitoring allows us to see not only the front-end response times but also what's happening with the back-end systems or infrastructure, making it much easier to identify and troubleshoot bottlenecks.

The tool is user-friendly and easy to learn, which is great for newcomers to performance testing. The challenge comes with scripting, especially for those without a programming background. Understanding code and modifying scripts with conditions requires some coding knowledge. Without it, it's less likely to fully utilize the tool.

One thing that comes to mind is TruClient. It's great for emulating real user behavior on an application, especially when you need to consider how the application interacts with the browser UI. It's like using a UFT script but directly within the browser.

However, the challenge is that TruClient can be very memory intensive. In most cases, clients' infrastructure simply can't handle the resource requirements for running extensive TruClient tests.

Ideally, there would be a way to address this memory bottleneck. We encountered a situation where a simple request-response test with HTTP wouldn't suffice. The user interaction involved a browser layer that needed to be factored in for realistic testing.

If OpenText could find a way to work around the memory issue, that would be very helpful. Here's why: sending a request and getting a response from the server is one thing. But users also want to consider the additional layer of the browser interacting with the application. 

To make the test as realistic as possible, you need to test it with different browsers. And to do that with multiple browser windows open, you really need a protocol that addresses this capability. It exists, but most clients can't handle the resource requirements for running such tests.

We have been using it for ten years. It has been quite some while. We are still using the version from 2022, we are yet to update the system. However, we are planning to upgrade it soon. 

Stability is alright. I would rate the stability a nine out of ten. The only reason I'm not giving it a ten is that sometimes the controller crashes when a test is about to finish. 

It can be frustrating, especially if you run a long test for an hour and it crashes near the end. You can recover the results, but it requires some effort. That's the main stability issue I've encountered. Other than that, it's pretty stable.

So, it can run stably for an hour on some occasions, but on others, it might crash within fifteen minutes.

For OpenText LoadRunner, it's just my team, so about five people in our organization. 

I'd rate the scalability a six out of ten. The main reason is that it's a very expensive application. Other companies might not be able to afford it. 

For example, if we need to test an application with 10,000 concurrent users, the license can cost a lot of money. That's where OpenText tools shoot themselves in the foot compared to other tools. Because of the price, many companies, like one I used to work for, decided not to renew their licenses and switched to open-source testing tools. 

Even though they might not get the same value, it's a cost they're willing to bear. So, the challenge to scaling up is the price.

We haven't encountered any truly complicated issues. Because we know how to use the tool for the most part. There was one time we couldn't resolve an issue ourselves and called support.

Positive

OpenText LoadRunner was the first tool I was introduced to since I started with performance testing.

I've never used anything else.

The deployment process itself isn't complex for us. Typically, the solution teams handle deployments using their own tools. We just test after the deployment is done. We're not really involved in the deployment itself.

We had a team of ten engineers for the deployment process. 

Moreover, the deployment time can vary between a couple of hours and a few days. The only time it might take longer is if there are external dependencies, where another team's deployment needs to happen first. But usually, deployments are a matter of hours, not minutes.

In South Africa, for a load license with about 5,000 concurrent users, the annual license, not including patches, is around 1.5 million to 2 million, depending on the currency exchange. That's a lot of money, especially for startups. 

Sometimes, you might have the license renewed for support, but if the application is stable, you might not need the annual fee. It can feel like throwing money away.

If they can afford it, then I would recommend it. It's a good product. The problem is the price. So, if they have the budget, then it's the best tool you can go for.

Overall, I would rate the solution an eight out of ten because if it weren't so expensive, I'd give it a nine and a half or even a ten. The price is really steep. 

It's an enterprise-level tool, but there are also smaller companies developing applications that need testing, and they might not have the budget for such expensive tools. So, if the price were more reasonable, it would be accessible to any size enterprise, big, medium, or small.

We are from a banking background and have a desktop application that follows the complicated .NET protocol. It has a lot of encryptions, and we use the solution to do the scripting. 

We use the Enterprise version because it's not possible to do scripting with open source. We initially started with Professional and then moved to Enterprise. 

OpenText LoadRunner Enterprise has improved the team's productivity. The results that I produce after the test help my team. 

The tool's most valuable features are scripting, correlations, and parameterization. Debugging is also easy. 

The debugging feature needs to include graphs. 

I have been using the solution for two years. 

The stability is good.

The product is scalable. 

The tool's support is good. Though they take time, they always fix my issues. 

Positive

We used JMeter before OpenText LoadRunner Enterprise. We switched to OpenText LoadRunner Enterprise because JMeter doesn't help to test encryptions and decryptions. 

OpenText LoadRunner Enterprise is worth its money. 

We used the Professional version and then moved to the enterprise version. We have subscribed to 1000 user licenses. The tool will be super expensive if we take up 5,000 user licenses. We have to limit ourselves on testing. 

OpenText LoadRunner Enterprise helped us overcome debugging and scripting challenges. It has enabled us to manage projects. We have a place where we can put our results and scripts. It has streamlined our testing process. The tool has improved productivity and result quality. 

I use LoadRunner Developer. The tool reduces and makes our lives easier by recording the workflow and helping us identify the correlation. 

LoadRunner helps us save time. We can create the scripts for dynamic parameterization and automatic correlation in two hours. Earlier, it used to take five to six hours. 

I rate the solution a nine out of ten. 

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.

Positive

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.