Cloud Load Testing: New Challenges in Testing Salesforce Lightning is the most popular CRM on the planet, and one of the most popular SaaS solutions in the world. In 2016, began marketing a new variation of their user interface that is focused on ease of use and speed, called Salesforce Lightning. The current UI, now dubbed “Salesforce Classic” is still available to all customers who use it. However, the intention of Salesforce is to eventually move all customers on to the new Lightning UI.

So, what do you need to know to prepare for this upcoming change?  Especially, are there any considerations to take when it comes to testing?

What is is a CRM platform that provides multiple cloud services to manage your organization’s sales, marketing, and customer support, by providing helpful tools for administration of contacts, campaigns, reports,  groups, calendars, accounts, and opportunities. Being that was a pioneer in the cloud, it has always provided a developer environment enabled for companies that wanted to customize their own data structures into the platform. This ability to test and customize is a great benefit to enterprise organizations, but also adds a great deal of complexity when consider how to test all of these potential permutations.

What is CRM?

A CRM system is a broad solution encompassing sales, customer service, business development, recruiting, marketing, or any other line of customer-driven business.  These platforms help to manage the external interactions and relationships to allow those in customer-facing roles to do their jobs more efficiently.

What is Salesforce Lightning vs. Classic?

Salesforce classic is the famous appearance that the platform has become well-known for. It’s an easy and straightforward solution for Sales; however, it was relatively limited for new features that Salesforce looked to release.  In 2015 the interface was redesigned with the lightning theme, and that brought other functionalities and sophisticated features that came accompanied with simple wizard-style navigation helpers. Even though Salesforce has released this new option for the UI, it still offers both views for all customers, for the time being, so you can pick between them and choose the one you prefer.  

Salesforce Lightning UI

Salesforce Classic UI

How should I measure the performance of Lightning vs. Classic?

There are some options for load testing cloud applications such as Traditionally, the best approach would be to simulate traffic at the protocol (HTTP) level.  In turn, we could measure the response time from, typically using tools like JMeter or Gatling for each environment.

One drawback of these tools is that they won’t reflect the render time of the user interface components seen by a real user, because traditionally these tools don’t load all of the elements in the browser needed to display the complete page.  A real browser is required to perform the task of measuring accurate page load time, and there are specific tools we recommend for that – such as Flood Element and Selenium.

What is Flood Element?

Flood Element is a load generation tool which uses the Google Chrome web browser in headless mode (via puppeteer) to generate load on a web application. By running Element in Flood, you can simulate thousands of browser instances running a predefined test script to simulate a series of user interactions. Flood Element test scripts are written in TypeScript and follow a very similar syntax to Selenium.

What did we observe when writing tests for Salesforce Classic vs. Salesforce Lightning?

Our main observations from trying to script a simple scenario to log in and add contacts, accounts, and opportunities:

  1. We found out that the Classic theme was extremely easy for extracting CSS selectors and XPaths. These selectors are needed to define the object we want to perform an action on.
  2. We noticed that the code created to test Classic is more straightforward, which speeds up response times. On the other hand, the scripting for Lightning was more complicated, because the CSS and XPaths had sticky dynamic values that take time to execute in between step actions. We also realized that the DOM content contains more complexity and it was harder to find the definitions for the objects and that also delayed our tasks.

Here, we’ve got a comparison of the selectors available for the Classic UI vs. the options available when selecting objects with the Lightning UI:

Classic UI

Lightning UI

The impact on the scripting is that the process of finding objects in Salesforce Lightning can be much trickier than doing so with Salesforce Classic: 

Creating a New Account in Salesforce Classic

step('Test: 06 - Fill New Accounts', async browser => {

		await browser.type(By.css('#acc2'), account)
		await browser.type(By.css('#acc10'), "9612338892")
		await browser.selectByText(By.css('#acc6'), "Prospect")
		await browser.selectByText(By.css('#acc14'), "Public")
		await browser.selectByText(By.css('#acc7'), "Other")
		await browser.takeScreenshot()


Creating a New Account in Salesforce Lightning

step('Test: 06 - Fill New Account', async browser => {
		await browser.type(By.xpath('//*[@id="90:4449;a"]'), account)
		await browser.type(By.xpath('//*[@id="115:3831;a"]'), "9612338892")
		await browser.type(By.xpath('//*[@id="4:3831;a"]/div/div[3]/div[1]/div/div/div/div/div/div[2]/div/ul/li[1]/a/span[2]'), "Antonio")
		await browser.selectByText(By.xpath('//*[@id="311:3831;a"]/div/div/a'), "Prospect")
		await browser.selectByText(By.xpath('//*[@id="357:3831;a"]/div/div/a'), "Public")
		await browser.selectByText(By.xpath('//*[@id="407:3831;a"]/div/div/a'), "Other")
		let linkSaveccount = await browser.findElement(By.xpath('/html/body/div[5]/div[2]/div[2]/div[2]/div/div[3]/div/button[3]'))
		await browser.takeScreenshot()


We’ve shared both test scripts on Github for your evaluation and comparison.

Overall,  we found the actual responses times were quicker in the Classic UI than the Lightning UI. Before jumping to conclusions about the speed of the Classic UI vs. the Lightning UI for human users, we must say that the complexity and features added in this new version are slowing down the script’s speed.  We plan to run some future benchmark tests looking at each transaction separately to parse out more detailed and exact information.

How to use Flood Element to test your own Salesforce instance?

The best way to start scripting in for testing purposes would be to get your Developers account here. Make sure to include your IP address as Network access to disable the 2FA that may cause your element script to hang up.

Putting It All Together

When you have your script created, you can upload it into Flood to execute it with 100’s or 1,000’s of concurrent users and try your hand at monitoring your load injectors. The free trial will provide you with enough node hours to execute this test outlined here for 1 hour with roughly 5,000 concurrent users.

If you are load testing using Flood, we’d love to hear from you. Drop us a note and share any ideas that are working for you and feel free to ask our team any of your tough questions!

Ready to get started?

Sign up or request a demo today.