Scheduling is the most valuable feature. You can run the test 24/7 and then integrate it into the on-premises internal APIs. How it connects to the internal APIs and how it secures the data is very important for us and definitely helped us.

It enables the creation of test data that can be used both for performance and functional testing of any application. Within the performance module of BlazeMeter, they have a different capability that supports performance testing. We have the performance test run on schedule, which is quite nice. It uses something called the Taurus framework. We built our own containers with the Taurus framework, but we moved to BlazeMeter because of the security vulnerabilities with Log4j. 

They've been more proactive in fixing those, but it was quite hard for us. We did it over five days, but they came back with the fixes in two days. We realized that their container solutions are much more secure. But at the same time, when it comes to [Runscope]. they have yet to add the data-driven approach, but they are really good. They support test data creation in their functional module, but there could be a few improvements made in test data management on [Runscope].

The ability to create performance and functional test data that can be used for testing any application is very important to our organization because we're looking at big loads of customers moving onto 5G standalone architecture. We're also looking at Narrowband IoT, machine-to-machine communications, and vehicle-to-vehicle communications. 

All of these require the new low latency tests, so that if we ship a piece of telecom equipment and move the customers onto the new 5G architecture, we can be confident enough to say, "Yes, this works perfectly."

Also, running those tests continuously means we can give assurance to our stakeholders and customers that we can build the applications in a way that can support the load. There are more than 20 million customers in the UK, and there's growing traffic on private networks and on IoT. As the technology shifts, we need to give assurance to our customers.

The ease of test data creation using BlazeMeter is the best part of the solution. I worked with them on the test data creation and how they provided feedback in the early days. It was really good. They have implemented it on the performance and mock services. Originally, we managed the test data on CSVs and then ran it with JMeter scripts. It was good, but the way BlazeMeter created mocks with regular expressions and the test data is quite nice. It reduced some of the challenges that we had, and managing some of the data on cloud is really good. 

The features are really cool, and it also shifts the testing to the left because even before you have the software, you can build a mock, build the test cases in [Runscope], and work on different API specifications. Then, you can actually test the application before it is deployed and even before any development. That feedback is quite useful.

BlazeMeter provides the functional module. They provide the performance testing, and it's all based on JMeter, which is really nice. JMeter is an open-source tool. You can upload your JMeter scripts back into the performance tab, and you can run off it. It's really brilliant and gives us the ability to run the test from anywhere in the world.

[Runscope] provides the capability to run test cases from different locations across the world, but we use it on-premises, which is quite nice. The reporting capability is really good. When the test fails, it sends a message. When it passes again, it sends a message. We know what's happening. The integration back into Teams is interesting because you can put the dashboard on Teams, which is nice.

It's really important that BlazeMeter is a cloud-based and open-source testing platform because for some of the functionalities, we don't always need to rely on BlazeMeter reporting. Their reporting is really good. Having the ability to use open-source tools means we can also publish it to our internal logging mechanisms. We have done loads of integrations. We also worked with them on developing the HTTP/2 plugin, which is now available open-source. 

The way they have collaborated and how they support open-source tools is really brilliant because that's how we came to know that the JMeter HTTP/2 plugin was provided by BlazeMeter, so we contacted them. We already tried that open-source tool and it was working at that stage. We started off with the mocks, using open API specifications. They also provide free trial versions.

With the shift-left, we build a mock and then start to use [Runscope] to validate those test cases. At that stage, we know even before the application is deployed that we can actually get something moving. When the real application is available within that sprint, we already have cases that are being validated across mocks and immediately configure them with the real applications and real environment variables. For a majority of the time, it would work and sometimes it might be a case where we update the data and then at that stage, we get the test cases to work. The moment we do that, we put it on schedule 24/7, every hour or every half an hour, depending on the number of changes that we do on the specific nodes. We always know whether or not it works.

This solution absolutely helps us implement shift-left testing. We really started building our core network this year. Last year, it was all about the planning phase. We almost got our APIs and everything automated with the mocks. We started to use the feedback loop and knew which ones worked. We did a lot of work around our own automation frameworks and with [Runscope]. 

We stopped some of the work we did on our own automation frameworks and slowly started to move them into BlazeMeter. We knew that as long as the tool supported it, we would continue with that. If we hit a problem, then we would see. At this stage, a majority of the work is done on the BlazeMeter set of tools, which is really nice because we started off with our own JMeter data framework test.

BlazeMeter competes with the tools we have built in-house, and there's no way we can match their efficiency, which is why we slowly moved to BlazeMeter. The team loves it.

We also use BlazeMeter's ability to build test data on-the-fly. Sometimes when we run the test, we realize that some of the information has to be changed. I just click on it and it opens on a web interface. I'll update the number in my columns because CSV also displays it as a table. For us, it's a lot easier. We don't have to go back into Excel, open a CSA, manipulate the data, do a git check, etc.

I like that the fly test data meets compliance standards because you get that feedback immediately, and it's not like they're holding the data somewhere else. We can also pull in the data from our own systems. It's all encrypted, so it's secure.

Generating reports off BlazeMeter is also quite nice. You can just click export or you can click on executed reports.

It's a great platform because it's a SaaS solution, but it also builds on-premises hosting solutions, so we have implemented a hybrid approach. BlazeMeter sets us up for our traditional hosting platforms and application stack as well as the modern cloud-based or SaaS-based application technologies. 

The solution is completely built on an open-source stack. Before performance testing, we used JMeter. There's flexibility in choosing Gatling, Locust, Taurus, or other open-source technologies. We're able to attract good talent in the market. They like open-source because it's lightweight, accessible, and quick. That's been a strong point.

We integrated user access management, so it's easy for consumers to actually use it. It has great reporting features and integrations. It can connect to AppDynamics, Dynatrace, and Splunk. 

Another great feature is that it meets the various maturity levels in our organization. We still have manual-based testing, and there are some teams that are very engineering and code focused. BlazeMeter helps meet all those maturity levels.

For example, a manual tester who wants to get into automation can use the scriptless feature. Even business people can use the record and playback function and record the business process. That is captured into JMeter and Selenium scripts, and they can continue executing that.

The solution enables the creation of test data that can be used both for the performance and functional testing of any application. Currently, we aren't using the test data feature in BlazeMeter.

It took us a year to realize the benefits because we had to do the design work and the network enablement piece for teams to start using it at that scale.

BlazeMeter helps bridge Agile and CoE teams. We define CoE as the center of enablement, not a center of excellence. We don't have central teams. We use the hub and spoke model. The hub is basically the central enablement team. We provide BlazeMeter as a service in the bank, and we manage, maintain, and govern it, but individual teams have federated autonomy.

The solution helps us implement shift-left testing. We're still in that stage, and we have various maturity levels in our organization. We have between 6,000 and 7,000 engineers. Out of that, around 2,000 are manual testers. The maturity level across those many thousands of engineers is varied. Some teams have definitely embedded shift left, and BlazeMeter is good at that. They can use YAML files and start shifting left. That means the developers are able to have YAML definitions in their code to do smaller performance load tests.

We use the solution's scriptless testing functionality. We have many testers who use scriptless testing now. The record and playback function is also one of the key aspects.

The manual testers are definitely getting more confident that they can start moving toward automation. People are finding that the existing test automation helps to build their test cases quicker. They struggled with JMeter as a tool. They had to learn various nuances. With scriptless testing, recording, and playback, they don't have to worry about that.

BlazeMeter definitely decreased our test cycle times. During each cycle, we're saving between one to two hours. We enabled integration between BlazeMeter and AppDynamics, so people don't have to log into multiple tools to do their analysis. BlazeMeter provides a single pane of glass to do the analysis.

It essentially saves days in the sprint because they would execute a test, then go into AppDynamics, the SCOM, or the IIS logs. To fetch the IIS logs, they would have to wait for the operations team to give them access.

The orchestration feature is the most valuable. It's like the tourist backend component of BlazeMeter. It allows me to essentially give BlazeMeter multiple JMeter scripts and a YAML file, and it will orchestrate and execute that load test and all those scripts as I define them.

The reporting feature runs parallel with orchestration. BlazeMeter gives me aggregated reports, automates them, and allows me to execute scheduled tests easily on my on-premise infrastructure.

BlazeMeter's range of test tools is fantastic. BlazeMeter supports all sorts of different open-source tools, like JMeter and Gatling, and different web driver versions, like Python and YAML. If it's open-source, BlazeMeter supports it for the most part.

It's very important to me that BlazeMeter is a cloud-based and open-source testing platform because, from a consumer perspective, I don't have to host that infrastructure myself. Everything my end users interact with in the front-end UI is SaaS and cloud-based. We don't have to manage and deploy all of that, which takes a lot of burden off of my company.

The open-source testing platform is fantastic. They support all of the open-source tools, which gives us the latest and greatest that's out there. We don't have to deal with proprietary formats. A secondary bonus of being open-source and so widely used is that there is a tremendous amount of help and support for the tools that BlazeMeter supports.

In our company, various teams use BlazeMeter, particularly appreciating its cloud license software, which supports up to 5,000 users. 

BlazeMeter's cloud capabilities allow us to load test or simulate traffic from any location worldwide, such as Europe, North America, South America, Australia, and even specific cities like Delhi. So, with one cloud license, we can simulate user load from various locations globally.

This global simulation capability is a significant advantage of holding a cloud license with BlazeMeter.

We also tried the ShiftLeft testing approach with BlazeMeter.

The feature that stands out the most is their action groups. They act like functions or methods and code, allowing us to reuse portions of our tests. That also means we have a single point for maintenance when updates are required. Instead of updating a hundred different test cases, we update one action group, and the test cases using that action group will update.

The process is pretty straightforward. You can enter data into spreadsheets or use their test data generation feature. You can create thousands of data points if you want. We aren't currently using it to create that much data, but it could easily be used to scale to that. The solution includes a broad range of test tools, including functional tests, performance tests, API testing, etc. They're continuously expanding their features. 

I also like that it's a cloud-based solution, which gives me a single point of execution and reporting. That's great because we can take links to executed test cases and send those to developers. If they have questions, the developers can follow that link to the test and duplicate it or run the test for themselves.

A cloud solution can be a little bit slower than an on-premises client or maintaining test cases locally on our machine. However, we've also run into issues with that. Sometimes people mess up and push the latest changes to the repository. That's not a problem with BlazeMeter because we're doing all the work in the cloud.

Out of all the functional tests, scriptless testing has been the standout piece for my team because it's cloud-based. It's easy for everybody to get into the navigation, and it's pretty intuitive. There's a recorder that's already built into it. It's easy to get started writing test cases with scriptless testing.

BlazeMeter's object repository provides a single point of update for us with regard to locators or selectors for our web elements. It's the same with the action groups. It's incredibly valuable to have reusable action groups that give us a single point for maintenance. It saves a ton of maintenance time.

The most valuable features of the solution stem from the fact that BlazeMeter provides easy access to its users while also ensuring that its reporting functionalities are good. Users can schedule BlazeMeter to run, especially when the need to build a new application comes up since it allows them to manage and know the performance parameters easily.

Using cloud-based load generators is highly valuable to us, as we can test from outside our network and increase load generation without having to upscale our hardware as much. The cloud load generator is there when we need it and is the feature we leverage the most.

We have a very high opinion of the range of test tools the solution provides, it has a great deal of potential and we are just scratching the surface of it currently. As our maturity and skillset with the product increase, we'll be able to leverage that more. For example, we don't really use mock services yet. We know how to, but we're still set in some of our ways. 

BlazeMeter being cloud-based and open-source is vital; it was one of our top priorities when choosing a solution. Much like the rest of the world, we're moving away from the old paradigm of the Windows days where we would bring up a server, get Windows licenses, an operating system, and maintain it all. With BlazeMeter, most of that is done for us, and we don't have to worry about infrastructure. We have on-prem load generators for teams needing to run load tests from within our network, and we need to maintain that capacity. However, we don't have to host anything outside of the load generators in the network, so the maintenance effort and cost are much less than they would be as a legacy system.  

The solution does bridge Agile and CoE teams. It's a shift-left tool, and testing comes in much earlier than in the past. BlazeMeter is a valuable asset in this regard. 

The tool helped us to implement shift-left testing. Many of our teams with the required skillset can include performance testing as part of their build runs. This may not be high-level testing; internally, we refer to it as early performance testing. It allows teams to confirm the software is functioning correctly early, which was not the case before. We would wait until a certain point in the SDLC before running a performance check, and now we're able to implement that much earlier in the process. 

We currently don't have any stats on changes in our test cycle times, but there is no doubt in my mind that BlazeMeter improved our software quality.

We have not faced challenges in getting multiple teams to adopt BlazeMeter. We onboarded around 50 users in three quarters, which is incredible considering we had two performance testers before implementing the solution. Our only challenge is skill sets, our staff wants to adopt the tool and understand its importance, but they may not have the resources or skillset to do so. Those with the necessary skillset are onboarded as soon as their project is greenlighted. 

BlazeMeter's most valuable feature is its cloud-based platform for performance testing. It means you don't have to worry about having your own devices or servers when testing web applications, as BlazeMeter provides the virtual devices you need for realistic testing.

The most valuable feature of the solution is that I like its workspace and shareability of resources, allowing multiple people to access the same scripts and use them in different environments. The extensibility that the tool offers across environments and teams is valuable.

BlazeMeter is a very good tool to add users and ramp up things, making them a few of its very good features.

The most valuable aspect of BlazeMeter is its user-friendly nature, ability to conduct distributed load testing and comprehensive analysis and reporting features. It particularly excels in providing a clear and organized view of load test results.

BlazeMeter is quite fast and can be accessed through the web browser.

It is a good choice for people transitioning to cloud-based load testing tools and its most valuable features are its strong community support, user-friendly interface, and flexible capacity options.

There are some advantageous features that are available in BlazeMeter. The type of HTML reports that can be downloaded from BlazeMeter can be shown to the clients so that they can be provided with a clear picture in a clean way, allowing even a layperson to be able to understand the metrics our company shows with the help of BlazeMeter.

For me, the best part is that we can graphically see the test result at runtime. It helps us understand the behavior of the application during all stages of the test.

BlazeMeter is a cloud-based and open-source testing platform, which is very important for us because we can be sure that we're using a tool that follows market trends and stays up-to-date.

The baseline comparison in BlazeMeter is very easy, especially considering the different tests that users can easily compare. The response time and the calls we make in our company are easy to trace with the help of BlazeMeter.

One thing that we are doing a lot with the solution, and it's very good, is orchestrating a lot of JMeter agents. This feature has helped us a lot because we can reuse other vendors' performance scripts that they have used with JMeter before.

It can also be used for both performance and functional testing of any application and we can manage different kinds of data to better cover the performance and functional testing of the applications. For example, if we need different kinds of data to test the different uses of an application, we can use this platform to help us with that. 

Another thing we like is that while it's difficult sometimes to connect this kind of performance test solution with application performance monitoring solutions, BlazeMeter has been great. Our experience with that has been great.

BlazeMeter is the perfect tool for us because it works with cloud and open source and other vendors' solutions. It's very good with other testing solutions in both our and our customers' ecosystems. For example, it's very good for perfecting mobile solutions and with other test data management solutions. It's very easy to integrate it into the software testing processes and tools that our customers are using.

It's also very good at bridging Agile and CoE teams. One thing that we are exploring right now, to make sure it works correctly, is the integration of BlazeMeter in the continuous integration and continuous delivery journey.

BlazeMeter can be used for both API and performance testing, it is a multi-facility tool.

The most valuable features for us are the API monitoring and the Mock Services.

Another good thing is that we can upload JMX files and schedule and monitor performance testing. We are able to share results and see reports that we can't get in JMeter. In that way, the performance testing is good.

In terms of the range of test tools, when there are API calls we can do automation testing, functional testing, performance testing, and use the Mock Services to create a situation that the APIs are down. We are able to handle everything that has to do with APIs. Whatever we have to test—the functionality, the behavior—we are able to do so with the help of BlazeMeter.

It has a unique programming dashboard that is very user-friendly. The auto-collision feature is also robust. 

The most valuable feature of the solution is its ability to run high loads and generate reports.

The solution is easy to navigate. 

The testing it offers is very useful and compatible with many platforms.

We don't have to maintain any infrastructure, as that is already provided by BlazeMeter. 

The real user monitoring feature is great.

I like that you can integrate JMeter script into the solution and run your load while testing a number of users.

The solution easily runs with end-user experience monitoring and you can run scripts right in the solution. 

The initial setup is pretty straightforward. 

The stability is good. 

The solution can scale. 

We have found the technical support to be quite helpful.

The pricing is quite reasonable.

• Simplicity
• Easy integration of open source tools
• Moderate migration of ALM scripts.

I really like the ability to spin up as many load generators as I need, and get statistics on response times and the load generators themselves. BlazeMeter support and flexibility is also hugely valuable.

To accurately test load on a webserver it takes traffic (load) from multiple “load generators”.
A load generator is a machine running load testing software (like Jmeter).
Clearly, one couldn’t accurately test 10 load balanced webservers with traffic from a standard desktop.
If one did and saw performance issues, the most likely source would be the desktop doing the testing, or the connection.
If no performance issues were seen it could be that the desktop was not able to emulate the specified load.

One blind spot of Jmeter is it does not tell the user how many threads their machine can handle. Users need to know how to monitor. Most users don’t, and set the threads higher than the machine can handle.
Blazemeter:

- Handles all that complication and makes using Jmeter simple

- Has expert staff that can point you in the right direction if your tests are not working

- Allows users to select how many load generators (machines running Jmeter) will be used during a given test.

o There are a few different contract options (1 server, 5 servers)

o Custom contracts for any number of servers you need. I really appreciate their flexibility on the contracts.

Providing the Cloud load generator is a good feature. We can run executions from multiple locations. Very few tools provide that. They have recently started with separate API testing. I haven't had a chance to use that yet but it might be very helpful. The solution offers flexibility with its configurations, taking around two to five minutes each. You can see the metrics in a graphical view while running the tests. Response times are also visible and can filter whatever we need and get the results of error loads. 

• The ability to quickly scale out a load test across the world, just to simulate realistic world traffic conditions.

Ability to generate heavy load (up to 5000 concurrent users)

Provide performance transactions summary & statistics

These features are valuable because, in my company, there is a requirement for the product to support up to 5000 concurrent users. As a performance engineer, it’s important to have a tool (like BlazeMeter) to generate heavy load and at the same time provide a report that shows how the system behaved under the load and provide performance statistics.

The ability to push large numbers of simulated users at our applications and having access to detailed reports: This helps us to have peace of mind that our apps can stand up to production-level loads and beyond.

• Easy to make small changes to the test without reconfiguration, so we could step increases in load and find the limits without risk in breaking the test scripts. Consistent testing allows for confidence in the results and ease of use by the team.
• Integration with New Relic - provides insight as to why the test had the results and how we can improve them. New Relic was already in our tool belt, so it was nice to not need to change to an unfamiliar tool.
  

I like the BlazeMeter extension. It is a very good expansion. With it, you can record any type of performance script scenario, and you can generate in a JMeter script, Selenium, et cetera. That is a very good feature. 

If you want to do that, it is used mostly on performance testing, API Mocking, et cetera. The API Mocking capabilities are great.

For performance, it is a very good tool and we don't have too much to do. 

It is UI-based and you can select the load generator and it is auto-scalable. You can select the origin where we want to generate load from it. We can select the bandwidth, for example. 

It supports any number of features and has a lot of tutorials.

The solution is stable.

The most valuable feature is simply the ability to have a basic POST request while simulating many users at one time. Being able to determine either a number of iterations or having all users hit the application for a duration, are both useful options.

We were doing load testing. We were testing web servers, and we needed to confirm that our servers were performing as well as the old ones.

This is a customizable product.

The documentation is good.

The sharing works well.

The reuse of JMeter scripts has allowed us to have continuity with the past, meaning that we didn't need to change the way we write scripts and collaborate with business users. Furthermore, it has given us a common way to modelize our campaigns with different technical partners, or different development teams.

I really like the recording because, with JMeter, the recording takes me a lot of time to get used to. With, BlazeMeter the recording is quick.

The test scenario definition feature is extremely easy to use and makes configuring tests an extremely fast process. I have found this feature to be the most valuable.

The metrics are a great feature for analyzing each test. Being able to see the errors compiled, along with their responses, has been very useful. 

We also love having the ability to compare multiple test results in one screen. The multi-test feature is very useful as well. The ease for creating tests in BlazeMeter has been wonderful.

The ability to scale JMeter tests easily. This isn't possible with traditional load testing approaches.

Load generation over cloud is the most valuable feature. This feature is most valuable for us because we use BlazeMeter for load testing. This helps us procure the required load generation infrastructure.

Other than URL testing, there are no pieces of this software that are actually useful to us.