LoadRunner Professional

We've been able to prevent possible performance impacts of applications

When a degradation does exist in production we can replicate and triage with driving traffic to our test regions

By adding validation to our transactions we can measure both for response time as well as accuracy in functionality

As we develop various integrated systems we can ensure they exist well without negative impact upon each other

As the response time numbers captured from HP LoadRunner seems to be more accurate, more clients trusted this tool for their application performance managements and they also used it for their benchmark/ baseline test.

Support from HP was tremendous whenever we got hung up in certain situations in some of our short term projects which had a tight deadline, which keeps those projects ongoing and we as a performance engineer team can deliver the result with minimal delay. This leaves a good mark on our clients.

As HP LoadRunner is upgrading and expanding every year, sometimes the new updated version for LoadRunner does not provide support for some critical older version protocols. In those cases, it had a negative impact on our business.

Enhanced Analysis feature and its correlation metrics between different runs in the analysis report (HTML) makes a high positive impact on our clients.

Go to tool for load testing on on premise servers

Used for 80% of applications with performance scope

It has been a huge help for our team to determine the impact our application was going through each release. With performance testing and with the tool as good as HP performance center, it enabled our team to build lighter software with good tech and system reviews happening for each release. Although I can't measure ROI in number, I would definitely say that we are building better software using the inputs from this tool.

It's ease of use and many inbuilt functionalities makes a performance tester's life a lot easier and efficient.

The scripts created with traditional web/http protocol are not robust thus re-scripting is required after most every code drop. Troubleshooting and fixing the issue takes more time therefore in most cases we do re-scripting to keep it simple and save time.

In ideal world you would rather spend more time doing testing than scripting in that case mostly you could use an Ajax TruClient protocol. This type of script will only fail when an object in the application is removed or changed completely. This way of scripting will save you more time and helps you maintain the scripts with less re-work effort on a release basis. On the long run you will have a better ROI when you use Ajax TruClient protocol for scripting.