BlazeMeter Reviews

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 gives us a centralized place to execute load tests, do reporting, and have different levels of user access control. BlazeMeter has a full API, which is the feature that's given us a lot of value. It allows us to integrate with BlazeMeter in our CI/CD pipelines, or any other fashion, using their APIs. It helps increase our speed of testing, our reporting, and our reporting consistency, and gives us a central repository for all of our tests, execution artifacts, and results.

BlazeMeter added a mock services portion. We used to leverage a different product for mock services, and now that's all done within BlazeMeter. Mock services help us tremendously with testing efforts and being able to mock out vendor calls or other downstream API calls that might impact our load testing efforts. We can very easily mock them out within the same platform that hosts our load tests. That's been a huge time saver and a great value add.

BlazeMeter absolutely helps bridge Agile and CoE teams. It gives us both options. BlazeMeter is designed so that we can grant access to whoever needs it. We can grant access to developers and anyone else on an Agile team. It allows us to shift left even farther than a traditional center of excellence approach would allow us.

It absolutely helps us implement shift-left testing. One of the biggest features of shifting left is BlazeMeter's full, open API. Regardless of the tools we're leveraging to build and deploy our applications, we can integrate them with BlazeMeter, whether that's Jenkins or some other pipeline technology. Because BlazeMeter has a full API, it lets us start tests, end tests, and edit tests. If we can name it, it can be done via the API. It tremendously helps us shift left, run tests on demand, and encode builds.

Overall, using BlazeMeter decreased our test cycle times, particularly because of the mock service availability and the ease with which we can stand out mock services, or in the case of an Agile approach, our development teams can stand out mock services to aid them in their testing. 

It's fast, and the ability to integrate with pipelines increases our velocity and allows us to test faster and get results back to the stakeholders even quicker than before.

The overall product is less costly than our past solutions, so we've absolutely saved money.

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.

BlazeMeter needs more granular access control. Currently, BlazeMeter controls everything at a workspace level, so a user can view or modify anything inside that workspace depending on their role. It would be nice if there was a more granular control where you could say, "This person can only do A, B, and C," or, "This user only has access to functional testing. This user only has access to mock services." That feature set doesn't currently exist.

I have used this solution for almost five years.

The stability has absolutely gotten better over the years. They had some challenges when they initially migrated the platform to GCP, but most of those were resolved. Overall, they have very high availability for their platform. If there's an issue, they have a status page where they publish updates to keep customers in the loop. 

If you email their support team or open a ticket through the application, they're always very quick to respond when there's a more global uptime issue or something like that. Overall, they have very high availability.

Technical support is absolutely phenomenal. I've worked with them very closely on many occasions. Whether it's because we found a bug on their side, or an issue we're having with our on-premises infrastructure, they're always there, always willing to support, and are very knowledgeable.

I would rate technical support as nine out of ten.

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.

From my company's side, I'm the "owner" of BlazeMeter. I worked with a support team to set up the on-premises infrastructure. I still work with them.

Deployment was straightforward and simple. We pulled some Docker images and deployed them. The whole on-premise deployment methodology is containerized, whether it's standalone unit servers running Docker or a Kubernetes deployment, which allows you to deploy on-premise BlazeMeter agents through a Kubernetes cluster and your own GCP environment or on-premises Kubernetes environment.

We worked directly with BlazeMeter.

We evaluated Load.io and a couple of other solutions. When we brought on BlazeMeter five years ago, they were absolutely the leader in the pack, and I believe they still are. They have a much more mature solution and an enterprise feel. The whole platform is much more developed and user-friendly than some of the other options we evaluated. 

I don't know if there are any features in other platforms that BlazeMeter didn't have; it was mostly the other way around. There were things BlazeMeter had that other platforms didn't have, and existing relationships with the company that used to own BlazeMeter, Broadcom.

I would rate this solution an eight out of ten. 

It's a fantastic solution and can do so many things. But unless you have a team that's already very experienced with JMeter and BlazeMeter, there will be some ramp-up time to get people used to the new platform. Once you're there, the features and functionality of BlazeMeter will let you do things that were absolutely not feasible on your previous platforms.

We don't really leverage the actual test data integration and creation functionality, but we leverage some of the synthetic data creation. BlazeMeter will let you synthetically generate data for load tests, API, or mock services. We have leveraged that, but we have not leveraged some of the more advanced functionality that ties in with test data management.

The ability to create both performance and functional testing data is not very important to us. A lot of the applications we test are very data-dependent and dependent on multiple downstream systems. We don't leverage a lot of the synthetic data creation, as much as some other organizations might.

We don't extensively use BlazeMeter's ability to build test data on-the-fly. We use it to synthetically generate some test data, but a majority of our applications rely on existing data. We mine that in the traditional sense. We don't generate a lot of synthetic test data or fresh test data for each execution.

BlazeMeter hasn't directly affected our ability to address test data challenges. We don't directly leverage a lot of the test data functionality built into BlazeMeter, but we're trying to move in that direction. We have a lot of other limitations on the consumer side that don't really let us leverage that as much as we could. It certainly seems like a great feature set that would be very valuable for a lot of customers, but so much of our testing is done with existing data.

We haven't had any significant challenges with getting our teams to adopt BlazeMeter. There were just typical obstacles when trying to get people to adopt anything that's new and foreign to them. Once most of our users actually spent time using the platform, they really enjoyed it and continued to use it. 

There were no significant hurdles. Their UI is very well-designed and user-friendly. Perforce puts a lot of effort into designing its features and functionalities to be user-friendly. I've participated in a few sessions with them for upcoming features and wire frameworks of new functionalities.

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. 

In load testing, BlazeMeter is utilized to create realistic user behavior. It's particularly friendly for web LoadRunner users, providing proper pacing and timing control. 

Moreover, it allows for comprehensive control over user behavior across scripts, such as ramp-up and steady-state phases, which is crucial for conducting incremental load tests and more. This level of control isn't as easily achievable with other tools, but with JMeter and BlazeMeter, it's possible.

Incremental load testing is a type of test you can perform with JMeter. It's a technique that isn't straightforward without BlazeMeter. BlazeMeter facilitates this process.

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.

An area for improvement could be enhancing BlazeMeter's integration with automation scripts. 

It would be beneficial if BlazeMeter could support automation frameworks more effectively, including the use of Selenium scripts for both manual and automated load testing.

Integration is one of the things lacking in BlazeMeter compared to some newer options. A lot of products are coming out, and BlazeMeter pricing is a factor. 

For example, LoadStorm by Neustar is integrated with built-in APMs. It won't capture all server stats, but it will collect the minimum important aspects – CPU consumption, utilization rate, and how much a single server is being stressed. If BlazeMeter offered similar functionality, it would be fantastic.

I started using it almost four years ago and continue to use it as needed.

I would rate the stability a six out of ten. It's good. But one suggestion – people tend to rate based on cost these days. Because of that pricing, there are a lot of other new technologies on the market. That's why some people integrate BlazeMeter with an Application Performance Monitor (APM) tool, like Elastic Search or Elastic module. You can pull anything, even CPU utilization or memory usage, by installing agents.

It's actually really good.  

BlazeMeter is a scalable product. It's user-friendly and easy to operate, which I find appealing.

I would rate the scalability a seven out of ten. 

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.

The setup process for BlazeMeter is simple.

The pricing is manageable. It is not that big. Big companies won't mind the licensing costs. However, Neustar has more reasonable pricing. 

Most people don't prefer Neustar, but it is a good solution. 

I specialize in load testing, so I use both LoadRunner and BlazeMeter in parallel. 

I've previously worked with other tools like Neustar, where we were able to simulate load similarly. A noteworthy aspect of these tools is the ability to integrate automation scripts for load testing, which enhances their utility.

Neustar is actually replacing LoadRunner in our current environment. If we want to do both automation and load testing, I would choose Nustar. We can create Selenium scripts directly in Neustar, and automation engineers can use Selenium to create scripts that can then be called within Neustar.

BlazeMeter meets our needs well. It performs admirably for our purposes.

Overall, I would rate the solution an eight out of ten. I would recommend using this solution to other users. 

I used it for a couple of projects, but I don't actively use it now.

We use it for performance testing, volume testing, stress testing, and endurance testing.

We use it for EPS, web HTTP HTML, SQM, RabbitMQ, and sometimes ActiveMQ. So, it handles various testing scenarios for me. 

It has been most effective in managing large-scale tests. It saves the test execution files to the repository. The tool also has a distributing/executing model. You can create a JMeter script or YAML and then execute it using different infrastructure-related configurations.

Moreover, it can be integrated with tools like ALM.

Running from the cloud with load distribution, it exhibits load from different geo-regions. The best feature is generating loads from different cloud regions.

I find these features useful for my particular use case because I can't execute or generate the load within my infrastructure. With the cloud, I can rent on a pay-per-use model and execute the load with a massive number of users.

Sometimes, when we execute tests, the results calculated by BlazeMeter, specifically the response times for failed transactions, are incorrect. We've already reported this issue. If this could be fixed, BlazeMeter would be a much better tool compared to LoadRunner.

Currently, it incorrectly calculates response times for failed transactions, it provides data that isn't useful. We have to manually aggregate the data to get accurate values.

In future releases, I'd like to see BlazeMeter integrate with mobile applications and allow testing on real devices.

By testing on real devices, we could gather metrics related to CPU usage, memory, and battery consumption. This would give us a better understanding of how the application performs on actual devices and help us ensure there are no battery drain issues, high internet usage, or excessive CPU or memory usage. This would allow us to confidently certify that the application is optimized for real-world device performance.

I work as a centre of excellence, so I've been working with JMeter and BlazeMeter for almost nine to ten years. 

For only BlazeMeter, it would be five to six years. BlazeMeter doesn't have versions, but JMeter is currently on version 5.6.3.

I would rate the stability a ten out of ten. There haven't been any outages, so I'm satisfied with the stability.

I would rate the scalability a nine out of ten. It scales well. When the load generators get overloaded, it automatically distributes the load to new instances.

We don't very actively use it right now, but we have used it in the past two years. If we have the opportunity and the client is looking for a cost-effective tool, we would definitely choose BlazeMeter.

My experience with the customer service and support have been very good. 

Positive

We used LoadRunner. The cost was the main reason for the switch.

I would rate my experience with the initial setup a nine out of ten, with ten being easy. It was straightforward, I didn't had any issues.

• Deployment Model: It's a SaaS model, so it's already available for use. We only need to create and upload our scripts.
• Integration with existing CI pipelines: Once a new build is ready, we have automated pipelines that trigger a load test on the deployed build. It then provides a result indicating whether it's a go or no-go based on the configured SLAs.

Our organization maintains BlazeMeter, not me. I'm a performance architect who uses BlazeMeter to assess application performance.

The cost is low, so there's a definite return on investment compared to LoadRunner. 

There is no direct ROI because we still pay for the product. But think of it this way: if I spend $100 on LoadRunner but only $10 on BlazeMeter, then the ROI is essentially the $90 saved. That's how we look at it.

I would rate the pricing a three out of ten, where one is very cheap, and ten is very expensive. 

We looked at NeoLoad. Here, also the cost was the primary factor.

Overall, I would rate it a nine out of ten. For me, it's a good product. 

It's a good tool for automation testing and performance testing, especially if you're looking for a high-performing, highly scalable, and cost-effective solution.

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

The tool fails to offer better parameterization to allow it to run the same script across different environments, making it a feature that needs a little improvement. The tool should offer some ease of use across environments.

The solution's scalability is an area of concern where improvements are required.

BlazeMeter was introduced a year ago in my new organization because we had a higher demand. My company is a customer of the product.

Stability-wise, I rate the solution an eight out of ten since my organization is still streamlining things at our end.

Scalability-wise, I rate the solution a seven or eight out of ten.

Technical support doesn't respond the moment you put up a query, so it takes time to get a response from the customer support team. The support team does respond with enough information.

I rate the technical support an eight out of ten.

Positive

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

The product's deployment phase is fine and is not difficult.

I can't comment on the time taken to install the solution since our organization uses a shared installation with our enterprise account. My team didn't need to actually install the product, so we just created our workspace, and that was it.

I rate the product's price two on a scale of one to ten, where one is very cheap, and ten is very expensive. The solution is not expensive.

Maintenance-wise, the product is fine.

Based on my initial perception and initial experiences, I rate the overall tool an eight out of ten.

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

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 only downside of BlazeMeter is that it is a bit expensive.

I have been using BlazeMeter for three years.

BlazeMeter has been stable without downtime, and any performance issues are usually linked to the tested application, not BlazeMeter.

The product is fairly scalable.

BlazeMeter's tech support team has been excellent, providing helpful and responsive assistance through chat and email whenever we needed it. I would rate them as a nine out of ten.

Positive

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.

The initial setup is not too complex. It mainly involves configuring IP addresses and server communication, but it is a basic process similar to other tools.

BlazeMeter is more affordable than some alternatives on the market, but it is still expensive.

I would recommend giving BlazeMeter a try because they offer competitive pricing, and you can negotiate for discounts. BlazeMeter is more affordable than other products on the market but uses emulators instead of actual devices, which might be acceptable depending on your testing needs and budget.Additionally, it allows you to carry over unused virtual users to the next subscription, which can accumulate and save you money. Overall, I would rate BlazeMeter as an eight out of ten.

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.

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.

There is a tab in Blazemeter named Request Stats Report where improvements are required. If I have to go and find a particular timeline, which might be in a 15 or 20-minute window, there are no places or options where I can enter the perfect or exact timelines I want to find. You have the pointers to drag from one place to another, but that doesn't give me much freedom to get or find a timeline. Basically, on a tab in Blazemeter named Request Stats Report, there should be the start time and end time. In BlazeMeter's Request Stats Report, users should have an option where they can select and manually enter the test start and test end time to get the stats for a particular time period.

Scalability is an area of concern in BlazeMeter, where improvements are required.

I have been using BlazeMeter for a year.

The load testing time in BlazeMeter is too high since, in our company, we have seen that it takes four to five minutes to do an entire load testing process, and after that, we run the tests, which is a big problem for us.

Stability-wise, I rate the solution a five out of ten.

I see certain limitations when it comes to the scalability part of BlazeMeter since, in our company, we have faced multiple interruptions, because of which we had to stop certain testing processes.

Scalability-wise, I rate the solution a five out of ten.

I cannot give you an exact number related to the number of users of BlazeMeter in our company since we are just one of the teams in the company that uses the tool. I believe that around 150 to 200 people in my company use BlazeMeter.

I rate the technical support an eight out of ten.

Positive

I only have experience with BlazeMeter.

I rate the product's initial setup around seven on a scale of one to ten, where one is a difficult setup, and ten is an easy setup.

The time taken for the deployment of BlazeMeter varies since we have multiple types of applications in our company. If I have to deploy something on BlazeMeter, the time range for the deployment process can be somewhere between 30 to 120 minutes.

The solution is deployed on the cloud.

BlazeMeter is a supportive tool in terms of the fact that it is easy to migrate from one system to another. BlazeMeter offers an easy infrastructure that allows for migration, if needed, in a well-organized manner, but it is not an optimized tool yet since I still see a lot of problems in it.

I rate the overall tool a seven out of ten.

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

BlazeMeter is a very handy tool requiring drag and drop to operate., but I don't think I can generate a JMX file unless I run JMeter, which is one of my concerns when it comes to BlazeMeter. In our company, we are mostly unable to capture logs or events with BlazeMeter. We want BlazeMeter to assimilate a mobile app, especially sincere company deals in mobile apps, and we wish to conduct testing using BlazeMeter. The solution has been good so far, but JMeter is one area that has been tricky for me since I cannot generate events.

I cannot speak about a particular weakness in the tool, but it is a tricky product since those who want to use it need to depend on another tool called JMeter. JMeter is required to get the scripts and JMX file before being able to run on BlazeMeter.

In our company, an APK is generated whenever we develop mobile apps, and when I drag and drop it as a script, a JMX file should be generated, which is a feature not included in the solution. The aforementioned area where the solution lacks can be considered for improvement.

I have been using BlazeMeter for two months. I am currently an end user of the tool using BlazeMeter's trial version.

It is a stable solution. When we compare BlazeMeter with other tools in the market, I can say that the solution's overall performance has also been very good in our company.

It is a scalable solution, but our company currently uses the tool's free version, and we have not opted for its paid version. Considering the aforementioned fact, I can't comment on the solution's scalability though I have heard from one of my friends that the product's scalability is good.

Around 50 people can use the product in my company.

In my company, we haven't contacted the solution's technical support since we are still exploring the product as we are a startup company. We are conducting a trial of all the tools available to us so that we can choose the ones that suit our company at the end of the process.

The tool's implementation is done since my company deals more in mobile apps than web apps.

My company is a health app provider making our process or business completely different in the market. We want a product that is not an API to test the performance of our company's apps, so we consider BlazeMeter to be a good option.

My company is looking for options, like LoadRunner tools, that can be a better choice than BlazeMeter.

My company needs to search for better options since we feel that we will have around a million users once we launch our health app in India. I want a tool that can help me test the app's performance, especially if a million users are using it.

BlazeMeter is a tool that is easy to use.

Interface and report generation capabilities make the tool very handy for its users. The only tricky area in the solution is running BlazeMeter on JMeter, an open-source tool making it a very complex part for me.

There are different technical stacks in the market in which one needs to invest. After the testing phase, one may go for an expensive product in the market. Once there is a stable product in the market and the company can generate revenue, then it is feasible to go for the paid version, which is an option available in JMeter, so I can recommend it to others. BlazeMeter's paid version can be a bit expensive compared to JMeter.

I rate the overall product a nine out of ten.

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.

BlazeMeter opened up performance testing for us. Our old solution was a client-based performance testing tool, and for staff to access it, they needed to remotely connect to a Windows VM and book time with that controller. Now our tool is web-based, and we onboarded 12 to 14 teams to BlazeMeter, which would not have happened before. Our CoE team was the go-to for performance testing, but the solution has opened up the practice to the whole enterprise, making teams more self-sufficient, and that's the most significant benefit. Performance testing is no longer segregated to one team.

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. 

Our biggest challenge is the skill set required to operate the solution because we used to have a centralized performance testing team. Now we've opened it up to other teams; some needed to onboard new resources. The solution is simple and user-friendly, but we still need the right staff to use it.

We encountered some minor bugs, and I would like to have the ability to add load generators to workspaces without having to use APIs. We can't do that now, so we're beholden to the APIs.

We have been using the solution for about nine months.

The solution is very stable. We had a few issues with users getting 404 errors recently, but that's the first time we have encountered any problems in three quarters. 

The scalability is incredible. We could scale it to as big or small as we want, with our license being the sole limitation. The resources are in Docker containers in Docker images. We could scale within a few minutes if necessary. 

The technical support is excellent. When we had hiccups during deployment, they responded quickly with effective solutions for us.

Positive

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.

The deployment is very straightforward. That was one of our criteria, as we didn't want a complex new enterprise solution rollout. There were a few bumps during deployment, but most of that was on our side. BlazeMeter is relatively simple compared to other enterprise solutions we implemented.

Less than ten staff were involved in the deployment. We used Linux Enterprise to house the six on-premise load generators, and there were a couple of employees responsible for Docker, our solutions architect, and myself as the admin.

I don't have a concrete figure, but I can say once we sunset our old solution, that will save us a significant amount of money on infrastructure, licensing, and maintenance. I also think there is an ROI associated purely with the increased quality of our software, thanks to BlazeMeter.

The product isn't cheap, but it isn't the most expensive on the market. During our proof of concept, we discovered that you get what you pay for; we found a cheaper solution we tested to be full of bugs. Therefore, we are willing to pay the higher price tag for the quality BlazeMeter offers.

We carried out a proof of concept of four tools, which included BlazeMeter. It's more stable and mature, with well-documented APIs. BlazeMeter University was a significant consideration for us due to our requirements; it helped us roll out the solution to multiple teams. It seemed like APIs for the other solutions were an afterthought.

I would rate the solution an eight out of ten. 

The solution enables the creation of test data for performance and functional testing, but our use is focused on performance testing. We don't particularly use functional testing, but we are currently talking about using test data management for functional testing. We have our in-house automation framework, so the ability to create both functional and performance test data isn't a high priority for us.  

We don't use BlazeMeter's ability to build test data on-the-fly, not because we aren't aware of it, but because we are still at the early stages with the solution. Until fairly recently, just one other person and I were in charge of performance testing for the entire company, so having self-sufficient teams is an immense change for us as an organization.

I would say it's critical to have the appropriate skillsets among the staff as we could deploy just about any solution in an enterprise. Still, it won't be used to its total capacity without the proper skills. BlazeMeter showed us how little performance testing we were doing before and how vital increasing that footprint is. We've onboarded 50 users; that's 50 users who were not engaged less than a year ago and can all carry-out performance testing.

This solution can work very well for enterprise companies with a more advanced skill pool to draw from. For beginners in this area, specific skills such as JMeter scripting are required to use the application. It's easier to use than most solutions but requires a particular skill set to deploy and operate successfully. A good solutions architect and QA leads are essential in evaluating any product.

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.

With BlazeMeter, our main gains were in agility and efficiency in the execution of performance tests and delivery of post-test reports.

It has helped us to implement shift-left testing. It has certainly helped us to speed up the tests, and with that, we gained time to carry out tests in all development cycles.

It has the ability to build test data on-the-fly, and this on-the-fly test data meets compliance standards, which is very important for us. Real-time data helps us understand the behavior at each level of the test. So, we can define numbers that an application needs to achieve in the test to classify it as being OK or not. This data helps a lot in the real-time investigation. By looking at each level, we can identify the exact moment of degradation or “break”.

It decreased our test cycle times. I believe that we saved at least 50% of the time in preparation for the execution. Using BlazeMeter has greatly simplified our performance testing experience, especially the preparation part.

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 Timeline Report panel has no customization options. One feature that I missed was not having a time filter, which I had in ELK. For example, there are only filter requests for a time of less than 5 seconds.

I have been using this solution for approximately 1 year.

It is very stable. We haven't seen any instability or unavailability issues so far.

It is scalable as per our needs. In our working model, the only team that uses BlazeMeter is ours. This solution is used only by our team whose mission is to bring performance tests to projects and squads.

They are very good. In the beginning, they held a workshop with our team, and whenever we ask questions, we are attended to without any problem. I would rate them a ten out of ten.

Positive

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 was not involved in its deployment. In terms of maintenance, the only maintenance is setting up new servers for use. This configuration is usually performed by us in the Performance team.

I don't have access to the information about its cost. So, I can't say if we have seen an ROI and if we have reduced our test operating costs.

We did not review other products.

BlazeMeter brings agility and efficiency in the preparation and execution of performance tests. With this, we gain time which is used to increase the scope of tests and anticipate possible problems.

BlazeMeter didn't help bridge Agile and CoE teams because we have a specific team. So, there was no involvement of professionals who work with agile. We gained agility and efficiency, but there was no involvement of any external team.

I would rate BlazeMeter a nine out of ten.

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.

One of the projects for this client is completely based on Mock Services and, with the help of that functionality, we are able to complete end-to-end testing with all the dependent components.

There are third-company suppliers who provide components that need to be tested, but most of the time we do not get those components on time. Normally, we would wait until the development is completed and only then go for automation. But now, with the help of the Mock Services, once we get the source code, we upload it directly into the Mock Services and into the API monitoring. Once we get the tracers, we are ready to point to the actual instances and test things immediately. By the time we get to that stage, we are ready for the market. That means that even before getting the complete component, we can start working with something. There is no need to wait. As a result of the Mock Services, the time it takes us to develop API automation is minimized.

Also, we had a number of performance testing tools, but we had to integrate third-party applications for generating reports. That was a pain point for us when it came to showcasing things to stakeholders so that they could be aware of what was happening. But now, everything is available once the performance testing is completed. We can immediately see the reports, and when a test is running, I can share the execution page with anyone else, as a link. That means they can view exactly what is happening, moment by moment, regarding the response time, request time, and latency. That feature is not available in some of the other applications and possibly not in any of the other applications.

One of the areas that BlazeMeter benefits us is our test cycle times. In the past, if there was a defect with a component, we would have to wait until the issue was fixed. And even though we were not testing that particular component, because of the dependency of that component, we would have to wait until the issue was fixed. If it ended up going beyond the deadline for the release cycle, we would leave that test case for the next release.

With the help of the Mock Services, we are overcoming everything. Wherever we are facing issues, whether they will be long term or temporary, by implementing the Mock Services we can bypass the faulty components that are not needed for our particular testing. In that way, we are able to reduce our cycle times. In addition, we have some physical devices and network devices in our testing. It takes a week to create physical devices in a virtual way. Instead, with the Mock Services we are creating them in a minute, and that helps our end-to-end testing to be completed on time. The benefit of BlazeMeter's Mock Services is that it takes us through our testing early in the cycle.

In a single line of business, in a particular call flow, if we have 1,000 test cases per release, 100 to 200 of them are with the help of the Mock Services. That saves us time, money, and manpower.

And before we had BlazeMeter's API monitoring, if there were 10 components and anything was down, we would not be aware. We would not send a heartbeat every second to all of the components to check whether they were down or up. The API monitoring is a real benefit for us because we are able to schedule it for every 30 minutes or every hour, and we can keep on monitoring a component. If there is a failure, we will immediately be notified by email, even on the weekend. We can take action and report the situation to the data analyst and to the component people so that they can immediately work on fixing it.

The API monitoring is one of the most excellent tools we have come across because of the scheduling and the results. We are able to analyze how stable a component is based on that monitoring.

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.

One problem, while we are executing a test, is that it will take some time to download data. Let's say I'm performance testing with a high-end load configuration. It takes a minimum of three minutes or so to start the test itself. That's the bad part of the performance testing.

I don't think they can reduce that time because that's the functionality they have implemented in our BlazeMeter performance testing. But it's a pain point whenever we are running performance testing in a call or a demo, as well as in our live testing when all the business people are there.

The first time I run a given test, if it takes three minutes to download onto my server that's understandable. But every time I rerun the same test, it is downloaded again, because once the test is completed the files that were downloaded are removed. That means I have to wait for three to four minutes again.

We also had a call last week regarding secret keys. In JMX we have some Backend Listeners, such as Kibana, and there are usernames and passwords for them that we have to manually enter. When we upload the JMX file into BlazeMeter for performance testing, the usernames and passwords are viewable. Anyone who has access to BlazeMeter can download the JMX file and the usernames and passwords are visible to all those people. That's an issue with the performance testing.

Also, all the competitors have MQ protocol support, which is lacking in BlazeMeter's Mock Services. Having MQ protocol support in the Mock Services would be great for us. JDBC, the database communication, is also lacking. If we had those things, we would be completely satisfied with BlazeMeter's Mock Services. 

And for the API monitoring, we are missing a data-driven approach. If, for a single API call, we have 50 to 100 test cases, there should be no need for us to create multiple steps or to duplicate the test steps. Instead, if we had a data-driven approach available, we could directly add the test data into an Excel sheet and call it into the single test steps and achieve what we need to do. We have raised this concern to the Perforce team as well, and they said they are working on it.

I've been using BlazeMeter for two year.

It's stable. Sometimes we do face issues, but they are understandable things.

Every month or two months, something will happen in the back end. The UI will say, for example, that performance testing is down due to this or that reason, and that they are fixing it. Sometimes it affects our testing. We will be in a demo or in a call with our stakeholders where we are presenting and something will be down.

We will raise a support ticket and they will say they are analyzing it and fixing it. They won't take much time, but at that time, it's a pain point. But it happens in all tools. Because it is a cloud tool it's expected, but it's not happening very frequently, so we are happy with it.

We have weekly calls with the BlazeMeter support team, and that's a great thing. During those calls they will ask if there are any issues and whether we need something resolved. If we raise any concerns, they immediately help us during that call. If not, they will ask us to raise a ticket and they follow up on it on both sides—on the support side and with us. They will give us updates. I haven't seen any other companies do that. I have been amazed with the basic support.

We also get weekly updates on whatever the roadmap contains and the new features they are going to be implementing. If we have any doubts we address them in the call. We are using some other tools, but we haven't seen this much support from any other company. When it comes to support, Perforce is the best company I have ever come across.

Positive

We haven't had a chance to use the cloud services because of security issues related to our company. We only use the on-prem server. But the cloud services are one of the best things about BlazeMeter when comparing it with its competitors.

We have older tools, like CA DevTest, that we are still using due to dependencies on JMX, MQ, and JDBC steps that are not available with BlazeMeter. With DevTest we are able to handle a lot of the custom extensions. Instead of the Mock Services, we were using the CA DevTest Service Virtualization tool. We want to move completely to BlazeMeter but we can't because of those dependencies.

Ca DevTest is the main competitor, but it doesn't have the performance testing available. Both solutions have pluses and minuses.

DevTest is hard to use. It has too many features for Service Virtualization. If a beginner is trying to learn something in DevTest, it's hard. It might take a month or two months to get some understanding of what the DevTest tool does. BlazeMeter is very simple. Even for beginners, they give some options in the Mock Services. If you're a beginner, you can create a Mock Service and it gives you a description for each and every step. This way, beginners can easily adopt BlazeMeter.

In addition to the step-by-step demos, there is the BlazeMeter University. When we onboard people into BlazeMeter, we ask them to go through those courses. For example, if we are asking them to work on API monitoring, we have them do the course on API monitoring. Once they get the certification, we have them work on the API monitoring. With the BlazeMeter University, there is no need for us to have a separate KB on how it will work or how it will respond. Onboarding people into BlazeMeter is not a problem for us.

We were using the functional testing for APIs, but it has been disabled in our organization. I asked what was the purpose of disabling it and they said it was to make sure that everyone is using the API monitoring. Although we requested that they enable it again for our purposes, so far we haven't had much chance to explore the API functional testing.

Overall, I would rate the solution at seven out of 10 because I have sent some requirements for API monitoring and performance testing on Mock Services separately, to separate teams; things that should be introduced into BlazeMeter. Until those things are available, I am not able to use some of the components