JMeter vs Azure DevOps Services

• Easy of use - in generate load like HTTP requests, and processing/analyzing the responses. No coding is necessary at the basic level, just need to understand load testing and the infrastructure being tested.
• Automatic management of things like cookies to help with session state support - so you don't specifically have to worry about it or handle it
• Lots of testing/configuration options to suit your needs in making the right load generation (sampling requests), and analyzing the results, including any pre and post processing of the results first. Things like the Beanshell/BSF pre/post processors, response assertion, regular expression extractor, XPath extractor, CSV data set config
• There is a JMeter cloud service called BlazeMeter that I think would be useful for those that need to scale up high load without provisioning their own systems. I've not personally tried it though, but I recently attended a meetup presentation that highlighted nice useful features that BlazeMeter provides. One should evaluate the service if they are considering JMeter and need to expand beyond existing hardware resources.

Read full review

• Flexible Requirements Hierarchy Management: AZDO makes it easy to track items such as features or epics as a flat list, or as a hierarchy in which you can track the parent-child relationship.
• Fast Data Entry: AZDO was designed to facilitate quick data entry to capture work items quickly, while still enabling detailed capture of acceptance criteria and item properties.
• Excel Integration: AZDO stands out for its integration with MS Excel, which enables quick updates for bulk items.

Read full review

• Jmeter requires many tweaks with respect to its configuration file and thread properties. users need to edit theses files themselves. There could be some interface where we can edit this fields.
• Jmeter cannot handle more threads and hangs up when we increase the number of threads. This causes lot of inconvenience. In these situations, user can be notified that such change would be lead to slow performance so that user can do as required. The same appears when we try to view huge files on graph listener.
• Jmeter should optimize the read and write access to output csv since it acts as overhead to the I/O performance. This affects our test results for the application which we are testing.

Read full review

• Column sorting when in filtered states.
• A way to show cross-team dependencies.
• A customized "From" field for notifications. Sometimes when a mail comes from Azure DevOps the teams do not realize that I am sending it
• A way to do online poker that doesn't require a plug-in.

Read full review

• Gives liberty to developers and testers to perform testing. Easy to set up and run load tests, stress tests has improved testing.
• Enhances the performance testing which ensures the delivery of well-suited applications.
• The Enterprise messaging system, it's a great tool which helps in testing JMS based messages.

Read full review

• When I first VSTS it was with a team of developers who always work on their own. This project was the first one at the company that used six developers all work on the same product at the same time. Integrating someone else code into the system was an unknown entity. VSTS really helped move this new collaboration forward. The staff who were on this team then moved on work together on other teams because they knew how to handle this type of work.
• The learning curve on VSTS is quite large so make sure you have some of your best starting anew VSTS project. They will fail a few times but after a few mistakes they will get how to do things and your build, tests and deployments will all be automated.
• The user integration into VSTS is very good. As long as you developers can use Team Foundation Server source control, either Microsoft's or git, then they already have the permission to have VSTS access source control. This is very good.

Read full review