Salesforce Performance Sprint Testing

Salesforce release implementation is not optional events. It comes at least three times a year I am told. Upgrades to your system can be risky if no verification and validation activities are scheduled before these new Salesforce releases are implemented.

Of course, the business analysts can stop what they are doing and join with whatever IT test team is available to conduct manual system integration, regression, and acceptance testing. If Agile principles are in place, the project is broken into multiple sprint cycles that may last 4 to 6 weeks. It might be possible for the time to be reduced as much as 50%. This depends on what percentage of the time is regression testing compared to system integration and acceptance test time. The test tool or the test design must use artificial intelligence processing to minimize test crashes due to screen object changes.

As the title indicates this article is devoted to sprint testing Salesforce applications for performance integrity. I chose integrity because the focus should be more about system reliability during the sprint change impacts. The Salesforce releases should be introducing features and functions that maintain the systems reliability and scalability while continuing to enhance the user experience.

So, what does the Salesforce customer have to verify and validate performance? What can a customer do with performance in mind? I recently posted an article and a video that went into some detail on single-user performance testing with LoadRunner and its Network Virtualization tool. I believe this is a good job to add to a daily process to compare daily performance measurements. Just this effort can go a long way in detecting significant development change impacts. Browsers like Chrome and Firefox can provide related performance data in the browser developers network diagnostic reporting.

I am anxious to tell you more. It’s amazing the work that Salesforce personnel have done with their Salesforce sites:


I discovered from the HELP site that there is some discussion about a performance monitoring tool that is simple and easy-to-use. The tool uses a Java Server Page. The URL is as follows:

  • My Salesforce access name is like That means the domain is “companyname-dev-ed”.
  • Substitute MyDomainName with companyname-dev-ed.

The tool executes for a few minutes and displays some results that look like the following screen display.

Figure 1


Under the “Test Speed” button you will see the word “Finished” when the tool is completed its tests. The performance metrics shown is useful data. I especially like the Octane metric. This metric displays a number that indicates how well JavaScript download and script execution time works on your machine. If you are familiar with the internet Speed test utility, this tool shows you download and upload speeds. This is helpful in confirming your machine is adequate for using the Salesforce edition. And let’s not overlook the latency metric. You want to know if the hops to the Salesforce environment is reasonable in terms of time.

I added a short snapshot of a screen that provides some additional explanation. More detail can be found at the help site. One of the links is: Salesforce Performance Tool.

In figure 2 below are details that provide more description for the tool. But it also provides data concerning what measures are good and how to know when performance is not good. Remember, this is a tool to help with analyzing a client machine.

Let me take you back to my original reason for this article. As part of the sprint cycles, this type of testing could be established for daily communication with alerts to notify of unacceptable performance conditions. There are some other possible options to use during sprint cycles. I will mention them but I do not have much detail. If you are a customer of Salesforce, then you will have access to more detail when you sign up. Here are two other performance related test options to consider.

Figure 2