What is your primary use case for Micro Focus LoadRunner Enterprise?

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.

I use the solution in my company for any type of testing that supports LoadRunner's protocols, like your web testing or app.

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.

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 use OpenText LoadRunner Enterprise for load testing.

My organization uses OpenText LoadRunner Enterprise for anything related to browsers and the web. We have started using shift-left for applications. Costco primarily uses it for testing its various e-commerce applications and websites. We use the product to address challenges in performance testing within the applications.

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.

I use OpenText LoadRunner Enterprise to ensure the stability and performance of various technologies and platforms. We ensure that the platforms are performant and are able to run at the speeds the business requires. We also wanted to ensure stability as the code moves through our environment.

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

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.

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.

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.

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

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

The primary use case of the solution is for testing.

We use the solution for performance testing, including load testing and stress and endurance testing. We have worked with Citrix, Web-HTTP/HTML, Truclient Protocols and Mobile Applications as well. It has a good user interface and is user-friendly.

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

Performance testing is an integral part of the testing life cycle. It determines whether the application being rolled out for end-users is in line with our expectations. It contributes quite well. Initially, we had a completely on-premises implementation of LoadRunner. In 2018, we moved to cloud. The load generators are still internal, but the rest of the components sit in the Micro Focus cloud environment as a SaaS enterprise solution.

We use this solution for performance and load test different types of web-based applications and APIs. We want to make sure that before any application or any upgrade to an existing application is made available to an actual user, it is sufficiently tested within the organization. We want to ensure that if there is a high volume of users, they have a seamless experience. We don't want them to experience slowness or an interruption in service, as a result of an increase in the number of users on the web service or website. Essentially, we test to guarantee that all of our users have a good experience.

Initially, I've been using it for small use cases, just to test scenarios of less than 1,000 users. I think generally it's been very good. My team has even deployed it for clients within banking. It's still a go-to tool; although, as far as SaaS goes, recently we have had more suggestions to go with Neosyde.

I am a managed service provider, a reseller, and a consultant. In other words, I am a total geek. I added a whole bunch of features and changes three or four years, but I don't know if they followed my recommendations; however, they did implement some changes that I suggested. There's an onsite version and there's a cloud version. We typically don't want an enterprise type version because the clients that we work with are fairly large. The last place we used this solution employed 150,000 people. We have clients that have as few as 10 employees, and other clients that have thousands of employees. I would say the mid-sized businesses that we work with are between 250 and 700 people. It's all Citrix. We do load balance. We do load testing for Citrix deployments to determine whether or not we're going to get what we expected. The ability to run long packages for extended periods of time, and actually mimic end users. That's really what we use it for. We use it for validation. When you put together a system that has two to three thousand people on it, you need to be able to test it. To do that, you need a product that allows you to cast two to three thousand users on a system.

The primary use case for clients is that they often have large application development teams and application development projects that they needed to scale. So, for instance, if they were developing a new banking website and they needed to check that the application that sits on that website was scalable from a few hundred concurrent users to many thousands of users, they could test the load response using LoadRunner. That is what LoadRunner does, it does the performance testing and measures load-bearing response.

We use LoadRunner for performance testing.

The primary use case of this solution is for testing and for systems that we deploy in AWS, Azure, on-premises using Cisco UCS, and HP Hyperconverged. We need to know how the desktops are going to load and run daily. As an example, when you build a Citrix desktop and not paying attention, you can make mistakes. The next day, when someone is trying to log in, it may be that they can't because the mistake is on the desktop. Rather than risk errors, we perform load testing on new desktops and new desktop builds. That way, we know if they are done correctly, or if they have an issue then we can rectify it before going into production.

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

Even if the protocol and API doesn't cover your need, you can always find a solution. That means you can always handle any situation with a piece of code, whatever the target application is.