Anna Thorsen
Salesforce Lightning brings with it more features and a better user interface. It’s very customizable, but with this flexibility comes risk. And this risk continues to grow as the customizations and configurations in Salesforce grow.
Before you know it, you have mammoth software to test in order to ensure that all that tailored functionality does not disrupt business continuity.
Jump ahead to:
The risk of not testing enough
How to test custom forms in Salesforce
The Salesforce sandbox environments
Manual testing in Salesforce
Code-based Salesforce test automation
Codeless Salesforce test automation
Video: testing forms without code
The risk of not testing enough
Have you ever wondered what kind of risk are you opening your business up to by not testing Salesforce? The answer is: a heightened possibility of a break in your system that might prevent employees from doing their job. And let’s be honest, no one wants that kind of disruption in their day-to-day operations.
Let’s say you have made changes to several Salesforce forms by adding custom fields. If these forms are not properly tested before they reach the live instance of Salesforce, a bug could go undetected and lead to the loss of important business data. As we know all too well, the later a bug in the system is found, the more expensive it comes.
In this blog post, we’re going to talk about finding the most effective way to test Salesforce forms, and Salesforce at large, with automation.
How to test forms in Salesforce
If you are testing forms in Salesforce, you’re probably testing other areas of Salesforce too. Testing Salesforce should take place in a sandbox environment.
By doing so, any changes made in this environment will not affect your Salesforce production organization. We’ll detail the types of sandboxes below to help you find the environment that best suits your needs.
There are four types of sandbox environments, and they are available in most editions of Salesforce.
The Salesforce sandbox environments
A more detailed overview of the descriptions can be found on appfrontier.
- Developer Sandbox. Should be used for development and testing tasks in an isolated environment
- Developer Pro Sandbox. Useful for both developer and QA, user acceptance testing (UAT), and integration testing
- Partial Copy Sandbox. Predominantly a testing environment for QA - such as training, integration testing, and UAT
- Full Sandbox. Predominantly a testing environment to support staging, performance testing, and load testing
There are a few options available on how to test custom forms in Salesforce, and they can fall under three categories: Manual testing, code-based automated testing, and codeless automated testing.
Manual testing in Salesforce
Manual testing is often done by a dedicated testing team, but it can also be done by business users that have domain knowledge. This is referred to as user acceptance testing.
With development timelines accelerating, and constant changes being introduced to Salesforce, manual testing has quickly become a bottleneck in development and costly to scale.
Automation is the obvious candidate to bring change. But, somehow, we still see businesses using manual testing. Capgemini highlights this in their World Quality Report, where they state that only 15% of all testing is automated. And Salesforce is no exception.
Is there a reason for this? Yes, and we’ll cover it in more detail in the next section.
Code-based Salesforce test automation
Code-based automation is another approach to testing. There are open-sourced solutions like Selenium. And there are commercial technology-specific solutions too.
Related reading: Can You Use Selenium for Salesforce Testing?
These tools are highly technical, in that they require code-capable testers to develop, build and maintain the test automation. It’s difficult to onboard with tools like this because code-capable testers, especially ones that are proficient in APEX, are hard to come by. And those that are found are expensive to hire.
Now, that is not to say that code-capable testers are a not tremendous asset to have on your team. Rather, coding limits the number of people that can adopt and contribute to automation. This is concerning given that most testers in Salesforce are not code-capable, and are sometimes made up of Salesforce users.
If you couple this with the fact that test automation in Salesforce is extremely difficult because of its Dynamic elements and heavy DOM structure, it’s no wonder that people revert to manual testing approaches.
But not all test automation has to fall into this category. Some are much easier to adopt and maintain than others. Enter no-code automation.
Codeless Salesforce test automation
In the video below, you see an example of how to test the login of Salesforce, and how to test a lead submission form.
While the video is just a demonstration, the possibilities that this type of automation opens up are vast.
It requires no coding skills, which allows all testers and users to contribute to automation. This saves you time because you don’t have to rely on coding skills. In return, you’re able to release updates and customizations faster, sustaining the level of quality your business expects. And it means you don’t have to spend days manually regression testing with every change to Salesforce.
Want to see a case of automating the testing of adding an account and a contact in Salesforce without writing a single line of code? In this on-demand webinar, you’ll see a demo of how to build test automation for custom fields.
