We switched because we started off with a BDD framework that was done in-house. We realized that the number of security vulnerabilities that come off Docker containers was a risk to us.

We still continue with that work because we had to move toward mutual DLS in the wild too. We have that working at the moment, along with BlazeMeter. We've tried Postman, but it didn't support HTTP/2 when we looked a year and a half ago.

We previously used an HP product and we used LoadRunner for performance testing. 

We chose BlazeMeter because of the open-source technology. LoadRunner Performance Center is a proprietary tool. We had specialized engineers just on LoadRunner. They were expensive and difficult to get in the market. Key man dependency was a risk, so we wanted a platform with flexible tools and scalability. We also wanted a future-proof solution that would still be useful for the existing traditional tool set.

We previously used HP Performance Center. We used HP Virtual User Generator as a predecessor to JMeter for our scripting challenges.

We switched because it's a very outdated tool and toolset. BlazeMeter is a more modern solution. It supports many more tools, and it allows us to solve problems that were blocked by the old solution. 

The BlazeMeter platform is designed to be CI/CD, so it has continuous integration, it's continuous delivery-friendly, Agile-friendly, and it has all of the modern software development methodologies. 

Our old solution didn't really cooperate with that. It didn't have the API or any of the test data functionality that we've talked about with generating or pulling test data. It didn't have any of the mock services. BlazeMeter gave us the kind of one-stop-shop option that allows us to accelerate our development and velocity within our Agile space.

I used Micro Focus LoadRunner. I transitioned from my previous company to a different company. In my previous company, they used LoadRunner for customer projects, with a license for around 500 users.

I've faced a lot of issues with LoadRunner. Even with proper Java configuration, it throws exceptions when I run the first couple of servers. Because of that, I had to use a different VM and install everything from scratch. After that, things worked smoothly with BlazeMeter.

Additionally, I utilize JMeter for several products and Webber out of curiosity.

We were previously using Java and Selenium. We implemented BlazeMeter for the performance testing. When we discovered the functional test features, it was easy to pick up and start using. It was an accident that we stumbled into. Our use grew out of an initial curiosity of, "Let's see if we can create this test." And, "Oh, wow. That was really quick and easy." And it grew from there into a bunch more tests.

I have experience with LoadRunner and TAF.

We used other tools and switched because they weren't as user-friendly. BlazeMeter offered us the ability to increase our performance testing footprint without requiring a high level of performance testing expertise from our QA staff. Additionally, our old solutions were client-based, and BlazeMeter is cloud-based, providing all the advantages that come with that.

I have used LoadView and it is pricier and offers its scripting tool, but it is better in some aspects. While BlazeMeter primarily uses emulators for testing, LoadView utilizes actual devices and browsers, particularly for web applications.

I used mostly commercial IT tools in my previous organization, including JMeter.

We opted for BlazeMeter because it is accessible through the web browser.

I have experience with Grafana and JMeter.

Whenever a comparison is made between JMeter and BlazeMeter, there are a lot of differences one can observe. With JMeter, our company has to concentrate on the features as it is an open-source tool that works with Java. The configuration of the systems should have some high-end configuration, and the heap size depends upon the load our company uses. JMeter can be used in UI or GUI mode or in a non-GUI mode. If users have to go with a smoke test and the preparation of scripts, the GUI mode of JMeter can be used. For the actual execution of load testing, we have to go with JMeter's non-GUI mode. With the non-GUI mode, until the completion of the test, I could see the percentage of the error, but I couldn't see what kind of error was there in the application. In JMeter, I had to wait until the completion of the entire test. When we use the BlazeMeter cloud as a licensed tool in our company, we do have to deal with the setup of any configuration area. With BlazeMeter, whenever our company executes the load test, parallelly we can monitor what kind of errors we get, and if possible, we can have a word with the development team in parallel and we can solve all the issues so we don't need to wait until the completion of the tests as some of them may be longer than thirty minutes to an hour. In current situations, everything works in the cloud, and every request and every click gets counted in the cost. In BlazeMeter, there is no need to wait till completion of the one hour or until the end of the testing phase. BlazeMeter provides better reporting, but it takes much longer to do so, making it an area of concern where improvements are required. It is not always sufficient to only use BlazeMeter.

We didn't use any other solution. We performed the tests manually.

As soon as we got to know this tool, we realized how important it would be and the benefits it would bring to the company. Its main benefits have been gains in agility and efficiency. 

For the performance tests that we carry out in the company, we only use BlazeMeter. I don't know any other tools. My view of BlazeMeter is that it is a very mature tool that delivers what it has set out to deliver in an excellent way.

I only have experience with BlazeMeter.

We went with BlazeMeter because we can easily access the platform through the internet and because it is very easy to incorporate it into our processes.

I have used many similar solutions similar to BlazeMeter, such as JMeter, which I believe BlazeMeter is a customized version of JMeter. It is difficult to compare BlazeMeter to either Micro Focus LoadRunner or Tricentis NeoLoad because it is more of an open-source solution. You do not receive the high level of support that you do with paid solutions. You have to refer to the internet to resolve issues.

I use JMeter.

Though I have experience with a solution from OpenText, I feel BlazeMeter is the best. The main reason my company chose BlazeMeter was because it was preferred by one of our clients.

We also use LoadRunner.

I’ve used JMeter from several load generator servers I set up to work together.

We didn't have a previous solution. I personally came to this company in the past year and a half. I've always used BlazeMeter at my other companies and there was a big, gaping hole here. They were doing everything manually with running JMeter tests and this was just a natural fit.

We did not previously use a different solution.

We wanted a solution that was easy to interpret and wouldn't require custom tooling beyond building the test. JMeter was the right tool for the job, and BlazeMeter's expertise and easy to use interface allowed us to readily view and compare results without needing to build a custom workflow.

BlazeMeter was the first tool that I used.

I did not use any solution previously. I chose them because somebody else in my company had used them before, and had told me that they were very good.

I started working directly with Blazemeter. There is another person in the company who is using LoadRunner and it costs about $300 per year.

No, this was the first solution.

We did not previously use a different solution.

We did not use a previous solution.