OpenText Core Performance Engineering (LoadRunner Cloud) Reviews

We are using all the indexes and the features provided by the solution.

We have an infrastructure that is developed on the cloud. We use the product because it is more feasible to have our applications on the cloud. It is a trustworthy brand. The data I present to my customers are to the point. I do not have to check on the matrices again to verify whether it is false.

The reports are very relevant to the customers’ expectations. The tool has its own APIs for its customers. It is very easy to collect the performance data. In the last year, we have executed major tests multiple times. It's very easy to use the APIs to collect our results and create a dashboard as per our needs.

It is very important to us that we can plan and run tests using LoadRunner Cloud without having to manage testing infrastructure. It was a niche requirement for us not to bother about those things and focus on the main targets. It is the best thing that we can get. The solution saves us money by not having to maintain hardware and the power costs associated with the hardware. We have saved 25% of the cost.

The product must provide agents to monitor servers. If we want to monitor our servers, we should be able to do it by integrating the servers with LoadRunner Cloud’s dashboards. The added feature will enable us to see exactly what is happening in the servers at a particular time.

I have been using the solution for more than five years.

I haven’t seen any stability issues. The stability is good.

I have scaled the tool up to 1000 users. It comes with its cost.

I got a solution from the support team every time I had queries.

Positive

I have received an ROI from the product.

There are other tools that provide the cloud capabilities and key features that LoadRunner has, but LoadRunner‘s brand and trustworthiness are more important to me.

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

We are using it for web testing and mobile testing. I am sure we are going to do some API and microservice testing.

I love that we can plan and run tests using LoadRunner Cloud without having to manage testing infrastructure. That was a part of the reason we went to the cloud. It was not too bad to manage Silk Performer infrastructure, but it was still a pain. 

By moving to the cloud, I am hoping we can spend less time managing and more time testing. I also hope that LoadRunner Cloud will save us money by not having to maintain hardware and the power costs associated with that hardware, but only time will tell. I do not know it yet.

It is feature-rich. It supports most protocols, which is important because I am in charge of a team at the bank, and we do performance testing for all kinds of different applications. We have tons of them. We even do video streams.

While evaluating tools and saying that this is the tool we are going to go with, one of the biggest challenges that I faced was related to our previous experience with Micro Focus. LoadRunner and Silk Performer used to be under Micro Focus before OpenText bought it. Towards the end, Micro Focus did a big money grab where they went around and harshly audited all the companies. My company got hit with millions of dollars for the software that should have been removed. Even though no one was using it, we still got hit. It left a horrible taste and a horrible reputation for Micro Focus at my company. I know OpenText is a different company, but OpenText needs to somehow address and show former Micro Focus clients or LoadRunner clients, Silk Performer clients, and ALM clients that they are not the same company. I come to this conference and I get this message, but I have to try and sell that to my manager. The manager who got hit hard with the charge is not going to believe me. He still has that bad taste. They are influential people, and they remember that, so OpenText somehow has to overcome that.

Their documentation is not technical enough for us. We would like to have much deeper technical documentation so that we can self-serve without constantly having to go back to them and ask.

We have been using OpenText LoadRunner Cloud for a few months.

We are just setting up the environment. We have had some issues with load generators disconnecting. There is probably going to be room for improvement there. I understand that nothing is perfect, but if we are seeing that already, we rather not just see it.

We have not dealt with them so much yet. The support for Silk Performer was excellent. We had excellent resources and support. I would rate them a ten out of ten, but on the LoadRunner side, I am undecided. Time will tell.

We are being forced to move to OpenText LoadRunner Cloud because Silk Performer is going to end of life. We were Silk Performer clients for over 20 years at the bank. It is going to reach the end of life this year, so we were forced to pick a new product. 

It was difficult and time-consuming. We have great folks who are working with our value-added reseller and OpenText, but the challenge that we are finding is that we like to be a self-serve shop. They do send us articles about how to do something, which is cool, but they are not technical enough. They are missing details. We understand that their documentation needs to be at that general level for the people who are not so technical, but they need to have a second level that gets down into every port in security concerns. We need much deeper technical documentation available so that we do not have to constantly go back and ask. Overall, it was difficult. It could be worse. I am not unhappy, but there is room for improvement. 

OpenText is providing support to help with our transition to LoadRunner Cloud.

We should be seeing an ROI in the future.

LoadRunner always had expensive pricing. At my company, we used to evaluate LoadRunner, but we stuck with Silk Performer because its pricing was always better in the past. I do feel that I got a fair deal this time. Our value-added reseller and our sales guy worked hard to give us a fair deal. I feel that we got a fair deal.

We did not go for the pay-as-you-go deal. I did an upfront package. I prefer that. I want to know what my costs are.

We did a complete RFP process with multiple vendors with an open mind, but LoadRunner did win the process. We looked at BlazeMeter and k6. LoadRunner stood out in terms of features and the protocols it supported. It had the most features and the largest protocol support. The other vendors have not caught up yet. I know they are working on it, but LoadRunner has got that advantage right now. Others are behind on protocols. 

With all the vendors, we sat down for a long three-hour demo and did a day in the life. We showed them what we do with Silk Performer and asked them to show us how we would do this in their tool. LoadRunner won hands down. It was obviously not the same, but they could reproduce almost everything. It is a better tool. With other tools, we found big gaps. k6 had some gaps, and BlazeMeter had some gaps. They are not bad tools, but for what my team does, they would have handicapped us.

For now, I would rate LoadRunner Cloud a seven out of ten. That could go up or down.

It supports business applications for performance testing across various domains, such as retail, financial services, and banking. They had already procured a tool, LoadRunner, for use in their environment, whether on-prem or in the cloud. I've worked on numerous use cases that vary depending on the sector, like banking or insurance, as each sector has its requirements.

This tool has specific components, like LoadRunner Virtual User Generator for scripting, and execution windows, such as LoadRunner Cloud or Performance Center. It’s divided into three parts: scripting and code development are handled by one component, execution by another, and analysis by a separate file. This makes it user-friendly and easy to understand. In comparison, JMeter, which is open-source, can feel a bit clumsy. NeoLoad, on the other hand, is a good alternative and performs well, as I’ve worked with both. However, due to customer requirements, I procured LoadRunner, and we continue to use it. So, there was no option but to go with LoadRunner. In terms of setup and usability, it’s straightforward. If I were to rate the leading tools in the market, LoadRunner comes first, followed by NeoLoad. Based on my experience and colleague feedback, these are the most commonly used project tools.

The main difference is the interface; the look and feel have changed, but the background setup and configuration remain the same. The project admin team had already set up LoadRunner Cloud in our environment.

Since AI plays a major role in today's world, many tools are expected to integrate with it. If LoadRunner has AI integration, that would be a great feature.

In past projects, including those with LoadRunner and NeoLoad, clients often asked about integrating CI/CD pipelines, such as using Jenkins to automate the triggering process. I’ve done POCs on this, and it’s possible. Once set up, the pipeline can automatically execute tests without manual intervention.

I have been using OpenText LoadRunner Cloud for ten years.

From your experience, there are typically two options when purchasing a license: with or without support. Opting for support has been beneficial, especially when issues arise.

For instance, you mentioned a colleague facing a problem where they couldn't capture an application's network due to some background package being installed. After raising a request, the vendor support team from OpenText connected within 24 hours, set up a meeting, and provided helpful suggestions. Although it took a few days to understand and resolve the issue fully, the support was proactive and responsive.

Both LoadRunner and NeoLoad seem to offer efficient and timely support, ensuring users can get assistance when needed, which adds value to the tools themselves.

Positive

It's quite simple and user-friendly. Anyone with some LoadRunner experience can easily adapt.

The cloud configuration setup and server access can be tricky, as we don't usually get direct access. Sometimes, even after the configuration is supposedly done, problems arise when we start testing. For example, after developing a script locally, I occasionally face issues executing it on the Cloud LoadRunner machine. The test doesn't start, and I can't review the results. This usually happens if the configuration isn't done properly. I have to check the cloud-based machines and verify the IP range of the virtual systems because Cloud LoadRunner doesn't use static IPs—it has a dynamic range. The IP range can vary, and it picks one by one where the problem arises.

When that happens, I need to check whether my application can access the cloud machines. We need to request firewall access, specifying the source and destination, to enable communication between the cloud machine and our application. On-prem setups are different; there’s a physical machine, and I have direct access. I can check the hostname of my application and verify access to the load generator. I can ping the machine, use Telnet, and quickly resolve the issue. The process feels more cumbersome in the cloud, especially when facing execution challenges.

I transitioned to the cloud just six months ago. I've worked on cloud-based environments for only six months after migrating from on-prem applications. This involved migrating existing scripts to the cloud and re-executing previous tests to compare performance between on-prem and cloud. The goal was to assess the differences between the two environments, as the client expects improved response times and overall performance due to the cloud's higher configurations. I’ve shared the results of these tests, which reflect those improvements

The pricing is high compared to other licensing tools like NeoLoad. It's not excessively expensive but higher than NeoLoad. However, in my experience, clients often weigh NeoLoad and LoadRunner equally. LoadRunner has been around for a long time, and while some companies have moved away from it, the higher pricing can be attributed to its support for multiple protocols. For instance, it supports over 40 protocols, including SAP, Citrix, Oracle databases, and batch testing. This wide range of protocol support is one reason for the higher cost. Depending on the applications being tested, whether desktop, Citrix or something else, you may need to purchase specific protocol-based licenses.

LoadRunner offers a free license for up to fifty users, which may not be adequate for most projects. Projects require more load to simulate real business scenarios, so a more comprehensive pricing model may be necessary.

Two main licensing budgets are to consider: one for LoadRunner and another for NeoLoad. If a project has no budget for purchasing a product and is looking for open-source tools, I highly recommend starting with Apache JMeter. However, it's important to note that JMeter may not be flexible enough for all requirements, especially for desktop applications, as it has limitations.

JMeter operates in a single interface and lacks commercial tools' structured reporting and usability features, making it less user-friendly. While it’s a good starting point due to being free, users may need extra effort to organize and interpret results.

We recently evaluated OpenText's LoadRunner and NeoLoad for a project. We engaged with both vendors to take demos and understand their licensing models. Generally, NeoLoad's pricing was comparable to LoadRunne

If it's in the cloud, there's a separate version called LoadRunner Cloud. We have both options on-prem and cloud. Some applications only support on-prem, while others are cloud-based, so we must test them in the cloud environment. In this account, we work with both environments. It's worth noting that around 90% of applications are moving to the cloud these days. In the cloud version of LoadRunner, the concept of manually adding load generators doesn't exist. You don't need to worry about adding load generators to the tool, a common challenge with on-prem setups. In on-prem projects, if there are ten load generators and others are using them, you must wait for availability before running your tests. LoadRunner Cloud automatically assigns the load generators.

If someone in my network is looking for a performance testing tool, I recommend LoadRunner, especially if the client has a sufficient budget. For clients using cloud-based applications, it's essential to consider LoadRunner's cloud environment, which requires specific infrastructure from OpenText. They can opt for the Performance Center without worrying about cloud infrastructure if their applications are on-premises.

The recommendation ultimately depends on whether their applications are cloud-based or on-premises. Additionally, pricing and supporting the required protocol play significant roles in decision-making. It’s important to assess which types of applications they are working with, such as web, Citrix, or Windows applications, to determine the necessary protocol licenses. Buying unnecessary protocols can lead to wasted expenses.

Overall, I rate the solution a nine-point five out of ten.

We used Load Runner Cloud particularly to do spike testing. 

The license is built such that it can be used across the entire year. The flexibility to use it across multiple applications for the year for various concurrencies and time periods works well for us.

The TCO has been optimized along with the total ROI. The product, being a part of the Gartner magic quadrant, helps score against some of the open-source products out there. This helps as there are certain regulators who look at technology adoption that is a part of the Gartner magic quadrant.

We used Load Runner Cloud particularly to do spike testing and it was great. 

The license can be used across the entire year. They make it flexible so that we can use it across multiple applications throughout the year for various concurrencies and time periods.

The TCO has been optimized along with the total ROI. 

The product being is part of the Gartner magic quadrant and scores well against open-source products. This helps us with certain regulators who look at technology adoption.

There are two features that I would want MicroFocus to work on.

1. It should have a feature to report with a 99.9 percentile success rate.

2. We should be creating a performance dashboard with InfluxDB OR ElasticSearch integration with Micro Focus Cloud LR. We need Micro Focus Cloud LR to send feeds to InfluxDB OR ElasticSearch for each run for:

1) Realtime PT result publishing
2) Trending between runs
3) Data mashing with Grafana/Chronograf
4) Live alerting

The feed from the Micro Focus Cloud LR instance to InfluxDB should be configured, or an integration touch point should be available for sending real-time feeds into the DBs.

I have been using and supporting Micro Focus LoadRunner Cloud for more than two years now. 

Features like spike testing and load per use are excellent features. Users who are looking at very high concurrency requirements yet need it only for a short interval can use the LR Cloud efficiently. The learning curve is very smooth, and there is enough documentation. 

We use OpenText LoadRunner Cloud for performance testing of our applications.

We migrated from on-premises LoadRunner Professional to LoadRunner Cloud because it offers geographically distributed compute resources that can be scaled up and down on demand, optimizing costs.

OpenText LoadRunner Cloud helps us save money through its flexible scheduling feature. We can shut down resources when not in use, minimizing costs.

OpenText LoadRunner Cloud eliminates the need for our own testing infrastructure when running tests.

We're interested in leveraging the scriptless automation capabilities available in several tools. Some of our less technically inclined manual QA testers find them insufficient. They crave drag-and-drop functionalities or more intuitive scriptless automation options. Scriptless automation is an area that can be improved.

I have been using OpenText LoadRunner Cloud for six months.

OpenText LoadRunner Cloud is scalable.

Our OpenText Account Manager coordinates with their technical support to ensure tickets are routed and resolved efficiently.

Positive

With nearly 400 virtual machines to migrate, transitioning from on-premises to the cloud wasn't quick, but it proved to be a smooth process.

OpenText helped us with the migration.

The pay-as-you-go licensing model included in our cloud migration is a valuable feature. It ensures we only pay for what we use, eliminating unnecessary fees during periods of low activity.

The pricing for OpenText LoadRunner Cloud is average.

I would rate OpenText LoadRunner Cloud a nine out of ten. While OpenText LoadRunner Cloud boasts many AML capabilities, we're still exploring its full potential.

When we test retail applications, which are hosted across the United Kingdom, we try to save the load generators on a cloud and then do load testing. This is to do with holiday readiness and to certify a few deployments to production in order to make sure that performance is not degraded. We use Micro Focus LoadRunner Cloud both for integrating with the CI/CD pipeline and for standalone instances.

It's a fast product, so you don't have much trouble in terms of maintenance overhead. You don't want to just look into configuring load generators, look for upgrades, and end up having that take up a lot of your time. With this solution, you just log in and you start using it. This means that there is a huge benefit in terms of the overhead of maintaining the infrastructure and the maintenance effort.

Some retailers have a global presence now, and you can spin the load generator from whatever location you need. You can easily run distributed load testing, rather than procuring the load test across the globe and then getting tunneling, etc. That's one of the great features.

LoadRunner Cloud's reporting features are valuable as well. We can get a quick PDF without having to analyze the local data and then imaging it in the report.

Sometimes, on private or a standalone instances we see users getting dropped off. You may have started to run your test with 2000 users, and you may see that a few users got dropped off. Finding the reason is always hectic. I haven't seen these issues on LoadRunner Cloud.

If you get a raw file on a standalone instance, you are on your own to splice and dice the results. I want to see errors versus response time, and I want to see how throughput was performing when there was a spike in error or response time at a certain period of time. These type of options are not available on LoadRunner Cloud, and they would make the user's life easier and would help him drill down to the exact time.

In the next release, it would be nice to have more coverage in terms of load generators. Then, you would be able to drill down on the raw research and analyze more in terms of response time spikes or errors.

CI/CD integration could be a little bit better. When there's a test and if you see that there are high response times in the test itself, it would be great to be able to send an alert. It would give a heads-up to the architect community or ops community.

I've used this solution for about a year.

I haven't seen any issues with stability during six to eight hours of continuous exhibition. There were no packet drops due to connectivity issues or any problems with regard to line monitoring.

I didn't have any problems adding users in tests with a maximum of around 3000 users. Once in a while, we have issues with refreshing.

We used Performance Center for ten years. We compared other solutions and decided to switch from standalone to SaaS-based. So, we went with LoadRunner Cloud. We felt that it was a bit expensive, but feature-wise, it was pretty much on par with products from competitors. Also, we didn't see any issues with scalability when we ran a higher competency task.

Other tools are available in the industry, but they're not user-friendly, or they have limited features. Some have issues with scalability.

The initial setup was definitely difficult in the earlier version. My team was sometimes not comfortable with the earlier version because there were a lot of issues with regard to the spinning of loads and data. There were limited options in terms of reporting. Also, there were very few graphs where you can monitor online compared to those in the current one. The current version is more mature and better.

Because we don't own anything, we created our account and then got started with the license.

When we compare the price of LoadRunner Cloud with that of products by other SaaS providers, it is a little bit on the higher side.

I would rate LoadRunner Cloud at nine out of ten because it is user-friendly. You don't have to have much coding experience for configurations.

I have been using it to analyze the performance of various enterprise systems like SAP, web applications, Oracle Labs, and mobile app applications as well. The objective of the performance testing is to assess the system and whether it can withstand an actual load.

One of the main benefits is that we don't need to worry about load generators. Before we had Loadrunner Cloud, we had 10 to 20 load generators, and we needed to maintain them. There were always upgrades. We would also have to configure the load generators when we were ready to test, and at times there was stuff to clean up. None of that is necessary anymore. We can concentrate most of our time on creating scripts and configuring Loadrunner based on our objectives. It's very easy for us. We don't need to worry about what happens in the backend or how the load is distributed.

A second advantage is the reporting system. Once a test is done, even if it's in continuous integration and continuous delivery, it automatically triggers and produces reports. We can send the reports to multiple dev teams whose developers are expecting the reports.

Another advantage of the solution is seen compared to others we have used, like JMeter, and IBM solutions. LoadRunner has reduced a lot of the time involved in the scripting cycle because of TruClient. We only need to record one time and we can configure it accordingly to create various scenarios. It has reduced scripting time by about 50 to 60 percent.

When we do mobile applications, every build can be tested with LoadRunner Cloud. Once the developer checks into a particular branch, we call it a mod branch, the performance test is already integrated into it. They can trigger it through their continuous pipeline. For mobile development platforms, it's very crucial because notifications and other things need to be tested before we send to prod. Notifications are very load-sensitive because they go to every user—it could be 10,000 or 20,000 users—and we previously had issues with this. Using LoadRunner Developer and continuous integration has helped us.

Recently I have found the TruClient tool to be very useful. My team is involved in a lot of performance testing of applications including mobile platforms and different types of web browsers. In those cases, LoadRunner TruClient is very crucial to testing the performance. TruClient is one of the best features, one I use every day to create load scenarios.

The fact that the solution supports multiple protocols such as open source, VuGen, TruWeb, TruClient, and SAP is very important because these protocols help us to concentrate on what is really needed to produce performance tests. If something is not supported, you have to use other tools or find other ways of assimilating loads. For example, when you are trying to create loads for web applications, if it's not TruClient, you need to find and analyze every call: What the HTTP request is, and what the other kinds of requests are that we need to call, and then correlate all the correlation identifiers. All of that is taken care of by TruClient and other protocols. That is actually very beneficial across all the platforms. For example, a SAP application might be tested for mobile. We can use a combination of the SAP protocol and TruClient protocol. The combinations are very helpful for performance testing.

LoadRunner Cloud gives you a lot of options, even for multi-browser or multi-device testing. It has been the main tool that can do everything; complete end-to-end performance testing.

The support for large-scale testing is also an important feature in our operations. We have thousands of users and it provides the best solution. You can have an unlimited number of users, although you would need to pay for them, but that's a different story. In our organization, the maximum number of users is currently about 20,000 to 30,000. It's a one-stop solution. I can configure my load on the cloud environment and have 30,000 virtual users on the cloud. I don't need to create the infrastructure locally and I don't have to maintain it. Everything is taken care of by the solution.

In addition, its ability to run unlimited concurrent tests without worrying about hardware availability helps eliminate hardware dependency. You don't need to have the load generators on your network. You don't need to maintain those systems and you don't need to have that kind of network capability. If you're testing on-prem, but you don't have the network capacity to scale up to millions of users, LoadRunner Cloud enables you to create virtual networks and use the cloud to generate those kinds of loads. You can then analyze what the impact will be to your system when you have millions of users. LoadRunner Cloud is the best way to do that.

When it comes to the CI pipeline, there were some limitations initially, but the latest version of LoadRunner is very helpful. They can integrate into the CI/CD pipeline. We are trying to put it into a complete CI/CD pipeline, but there are still some challenges when you try to run it through different protocols. The challenges are around how you can containerize applications. There are some limitations to some protocols, such as desktop. And when it comes to database testing, there are some things that we can't do through CI/CD.

For CI/CD, the previous versions may not be the right ones, but the latest version is definitely a step ahead. We are aiming for 100 percent, but we have achieved around 60 to 70 percent in CI/CD. Still, it's very good to have that capability.

Also, it would be helpful if Loadrunner Cloud had the same kind of enterprise environment where we had multiple models and options while creating the load profile. Not all the options are available in the LoadRunner Cloud. If they could be added, it would be good.

I've been using a LoadRunner solution for more than 10 years as part of my performance testing.

The efficiency of the scalability is a 10 out of 10. I have used multiple tools and LoadRunner is the best one in terms of efficiency. When it comes to cost-effectiveness of the scalability, I would give it an eight out of 10. Even though it's cloud, and you can have thousands of users, we are paying in the tens of thousands. It's not so cost-effective for a university like ours. We still have to justify why we need to spend so much money every financial year.

I have used OpenText technical support a couple of times and they have been very supportive. They're good.

The only problem with setup is that there might be some problems with the firewalls, configuring SSH and other things. We were initially using OpenText SiteScope but we had some issues getting all the metrics. With New Relic and Dynatrace, we stopped using SiteScope. Other than that, we didn't have any issues. It's pretty straightforward. You install LoadRunner, configure your virtual users, and create the environment.

Our initial deployment of the on-prem solution took a week to get everything done, including setting up the firewall, configuration files, and the protocols. The migration to Loadrunner Cloud is nothing. You can start triggering whatever code you had on-prem in the cloud. There really isn't any migration involved. It's pretty straightforward.

We have definitely seen return on our investment with Loadrunner Cloud. As I noted, we used to have many load generators and they are no longer used. That is saving us about $30,000. And Loadrunner costs 50 percent of what it used to cost us to run the same test in the cloud. We don't need a Windows Server license anymore or networking capabilities specifically for testing. Those are the kinds of savings we have seen from moving to the cloud.

Also, in the past, we used to write code. But with TruClient, while you need a performance tester, you don't need a programmer to write scripting. If you know the system, and if you know the objectives of performance testing, you can do the performance tests. No programming skills are needed. That also gives us leverage. We can use someone with performance testing capabilities, even though he might not be the best programmer. That has also reduced our costs by $10,000 a year.

I have extensively used JMeter as a performance testing tool. JMeter is free and also enables codeless scripting. Even without coding you can try running scripts. But where there is no comparison between JMeter and LoadRunner is when it comes to distributing load. LoadRunner stands out. With JMeter, it's very difficult to distribute the load. 

When it comes to creating reports, Loadrunner is best. You will spend most of your time analyzing what's happened with the test, analyzing bottlenecks and pain points with the performance parameters. But in JMeter, you have to manually collect everything: collate the results and produce the reports. Then you need to do a detailed analysis to find the bottlenecks and resource patterns. It is very difficult, but it's free. If you have the skill set and the time, you can use JMeter. But if you are time-constrained, and you want to actually concentrate on performance testing, use LoadRunner.

LoadRunner Cloud provides application performance and management tools to an extent, but not to the extent of New Relic or Splunk. We predominantly use New Relic to monitor application performance and in some cases we use Dynatrace as well. But LoadRunner Cloud doesn't have complete application performance monitoring metrics.

LoadRunner's Developer integration enables developers to script and run tests without leaving the developer ecosystem. It gives a complete IDE where you can develop the code and add your script. For example, if you are using a Java platform to code, and it has all the libraries and the IDE, you can integrate your load testing into your development. For us, because we don't have a single development cycle or ecosystem—we constantly move to various methods—that's where the IDE has limitations. It supports certain languages but it doesn't support everything. If we are using Go, for example, we might need to add certain libraries, so that's where it isn't helpful. But if you are purely on Java or core platforms, it will definitely help.

The Developer integration enables developers to add performance testing to their day-to-day tasks, but shift-left depends on your company's development strategy. If your whole culture supports shift-left, so that your quality assurance is embedded from the start of the development cycle, then shift-left works out. But in our case, we use a lot of packaged applications like Workday or SAP where we don't have much opportunity to work with their code. We do a lot of configurations and integrations. In that case, shift-left doesn't work as well. But whether you follow shift-left or shift-right, Loadrunner Cloud works.

For non-functional testing, LoadRunner is the best tool. I can recommend it to other people, to create specific tests from the smallest load to the highest level of load. I don't think any other commercial tool has that capability to create load performance testing. There is no other tool that gives this kind of experience for a load-testing professional. From end-to-end, starting from creating the load scenarios, to running them, and then reporting, LoadRunner is the best tool. You save a lot of time and, with LoadRunner Cloud, you are saving a lot of money. Go for it.

The solution is used for load performance testing activities.

The product supports a wide variety of technology compared to any other tool.

The product must improve support. The support team provides delayed responses. Many times, there are a lot of conversations between the support team and the technical team without any conclusions.

I have been using the solution for 14 to 15 years.

The tool is not perfectly stable.

Around 30 to 40 people use the tool in our organization.

The installation is not difficult, but it is a pretty lengthy process.

The product must improve its price. The solution’s price is considerably high. It is the highest in the market.

My company decided to use the product due to the technology support it provided. I would recommend the solution to someone with technology that other tools couldn’t support. Overall, I rate the solution a six out of ten.