We use this solution as a tester. When it comes to 5G, there are loads of changes because we're trying to build the first 5G core network with the standalone architecture. Everything is based on APIs and API-based communications with a new HTTP/2 protocol. When we build the core network, we constantly change and tweak the network.

When it comes to testing, whether it's with Postman or any other tool, normally we run the test, make sure it works, and then move on. I was pretty impressed with [Runscope] because we can keep the test running 24/7 and are able to see feedback at any time.

A proper feedback loop is enabled through their graphical user interface. We can add loads of validation criteria. As a team, if we make changes and something fails on the core service, we can actually find it. 

For example, we had a security patch that was deployed on one of the components. [Runscope] immediately identified that the network mode failed at that API layer. The monitoring capability allows us to provide fast feedback. 

We can also trigger it with Jenkins Pipelines. We can integrate it into our DevOps quite easily, and they have webhooks. The validation criteria is quite simple. Most of the team love it and the stakeholders love the feedback loop as well. They can look at it, run it, and see what's happening.

The final solution will be across four different locations. The performance will run in a specific location. [Runscope] will run across different locations and test different development environments. At the moment, it's only on two environments. One is a sandbox where we experiment, and one is a real environment where we test the core network.

There are around 10 to 15 people using the application, but some of them only view the results. They're not always checking whether it works or not. We have multiple endpoints.

We use the solution on-premises.

This solution is a big strategic piece for us. We wanted to replace the legacy performance testing capability with BlazeMeter's performance testing capability. That was our first use case. Now, it's a more strategic platform with GUI testing, API testing, mock services, service virtualization capability, and test data capabilities. We aren't using everything at the moment, but that is the strategic intent.

We faced some challenges in getting multiple teams to adopt BlazeMeter. This was a big transformation for us. We used LoadRunner for 10 years, so changing to BlazeMeter was definitely a bit challenging. Organizational change management was involved. We were able to use other online resources to learn how to use BlazeMeter. There was resistance from some teams.

This solution is used by 24 teams across 13 divisions. There are about 75 engineers using BlazeMeter, but usage is higher. This is a hybrid solution.

Our primary use case for BlazeMeter is performance testing. We leverage BlazeMeter as our enterprise performance testing platform. Multiple teams have access to it, and we execute all of our load tests with BlazeMeter and do all the reporting through it. We also use it for mock services.

We have a hybrid deployment model. The solution is hosted and maintained by BlazeMeter. We also have on-premise locations within our network that allow us to load test applications behind our corporate firewalls. That's for test environments and non-production applications that are not externally available. It's a hybrid role that is mostly SaaS, but the on-premises component allows us to execute those load tests and report the results back to the BlazeMeter SaaS solution.

The cloud provider is GCP. BlazeMeter also grants access to Azure and AWS locations which you can execute load tests from. They engaged with all three of the major cloud providers.

BlazeMeter is user-friendly and excellent. My company prefers the licensed version of BlazeMeter, which I occasionally use for scripting and designing on the CentOS site, specifically for creating real-world scenarios.

In LoadRunner, we currently cannot create realistic user load behavior as effectively.

I use BlazeMeter occasionally, depending on the project. It's not used for everything but when necessary, especially with JMeter, for specific testing scenarios. So, my use cases depend on and vary according to the project. 

We have a couple of use cases for BlazeMeter. One is performance testing. It allows us to aggregate the execution and reporting of our performance tests. We can also create automated functional tests relatively quickly compared to writing tests in a coded platform like Java.

Around 20 people in the QA department are using BlazeMeter to test Mendix- based applications. We're doing regression testing on 22 applications, and we have at least two environments that we interact with regularly: a development environment and a pre-production environment.

Most of my company's use cases related to the tool stem from the needs of our customers. Basically, my company deals in the area of using the tool for mimicking contact center-related scenarios. When a customer calls an agent, the tool helps check whether the agent answers the call.

We use the solution for enterprise performance testing of various technologies including web services, APIs, and web GUIs.

We deployed the solution to increase our performance testing footprint, which we needed to upscale for the maturity of our operation. 

We have six on-prem load generators on our network, and the rest of our deployment is in the cloud. It's a very simple architectural design.

I use BlazeMeter for our WebApp Performance Desk. It helps me test web apps, APIs, databases, and mobile apps.

My company started to use BlazeMeter since we wanted parallel runs and more penetration across teams with more ease, allowing better reporting. BlazeMeter doesn't do anything on its own since it uses the same script used in JMeter. BlazeMeter serves as a tool for orchestration, and to arrange better testing, parallel testing, and better reporting, making it easy for developers to use were some of the factors that led my company to opt for BlazeMeter.

The use cases of BlazeMeter encompass a wide range of scenarios, including loop load testing for API-level, web service, or web application load testing. The primary purpose is to simulate various types of loads. For instance, if the load originates from distributed load testing, opting for a dedicated cloud solution would be advisable. This allows testing applications from diverse geographic locations and handling traffic from different tiers effectively. JAMITA cloud is particularly recommended for this situation, as it efficiently manages infrastructure interfaces and resolves technical intricacies associated with infrastructure maintenance.

It simplifies the process by emphasizing the key aspects of writing, uploading, and running scripts for testing purposes.

We use the solution for performance testing. We create the safe to upload to BlazeMeter. Also, we can do standalone and combined load tests depending on the requirements.

I occasionally used BlazeMeter for load testing to get insights into log distribution and generate reports.

Whenever I am not able to record the script with the JMeter, I use BlazeMeter extensions to record the scripts. Whenever there is a need to execute something in the cloud, my company uses BlazeMeter.

Previously, to perform performance tests, we had to connect servers in the cloud, configure them to perform the test, and plot the results on a dashboard. BlazeMeter came to simplify all this work.

In terms of deployment, we are using local Linux servers (RHEL 7), and for the cloud, we are using EC2 servers with Amazon Linux. Our cloud provider is Amazon AWS.

I work in a bank where we use BlazeMeter to conduct our load testing or performance testing. In our company, we utilize multiple machines, and multiple projects are hosted on BlazeMeter.

We are using it to execute performance testing for our website and mobile applications, including e-commerce solutions, internet banking, and more.

Our applications are in a cloud environment and have a lot of users using them at the same time. We are looking to create a better experience for the users. We execute this kind of performance setting to establish a baseline for response times and we use it to reduce them.

We are both a customer of BlazeMeter and a partner that implements it for other customers.

I'm working for a telecommunications client. We are using BlazeMeter's Mock Services as a priority for performance testing, along with API monitoring. These functions are each used on different projects.

The solution is used as a performance system. 

As our company wanted to use a cloud solution, we opted for BlazeMeter instead of an on-premises load generator.

I use BlazeMeter for the different samplers it provides.

We primarily use the solution for performance testing. 

To load performance testing of web/mobile apps.

I mainly use BlazeMeter for scripting. I have a performance testing background, and can directly record my workload with the help of a BlazeMeter plugin. Once I've recorded I can modify a couple of enhancements. I can design my signature in BlazeMeter and choose multiple dedicated IPs, depending on our load. We are system integrators and I'm a senior engineer. 

We use BlazeMeter to run simple POST requests against our application to simulate heavy load. We can then monitor our application instances as well as our database to see where the bottlenecks are.

We used BlazeMeter for our performance testing. It allows us to run our tests on the local area network. Its primary use is to make sure that applications can handle a high load before going into the production environment. It will generate a report with the results.

The clients come up with some of the test cases and we have to validate them.

We use BlazeMeter to perform load testing on our different web portals. Starting from JMeter scripts and based on users' behavior, we use the BlazeMeter workspace to adjust ramp-up. We study contemporary users and different scenarios in order to meet business expectations in terms of the required SLA.

Our primary use case is to create processes for performance. I created a one time function and implemented it for 1,000 users. 

We have an AWS elastic beanstalk Node.js express backend with Mongodb that we expect to experience a significant amount of load in the coming weeks.