Salesforce sits at the heart of the enterprise. Today, it has become a foundational tool that supports numerous critical business processes. To that end, most enterprises have a fairly complex Salesforce environment that includes a variety of customizations and partner integrations via the Salesforce AppExchange. Ultimately, Salesforce integrates with and gets data from a multitude of other systems within the enterprise to become the true “Customer 360” platform.
This setup powers valuable outcomes to help organizations grow, but the complexity of it also creates a unique set of challenges. Specifically, today’s Salesforce environments involve a lot of moving parts: There’s a lot that can change,and it can change quite frequently. Keeping up with these changes is the only way to continue increasing value for end users on a regular basis, but doing so proves difficult because of all of the moving parts.
However, there is a way to keep pace with these changes and efficiently deliver value to users; it centers around aligning Salesforce testing with DevOps release processes to create an environment in which “Customer 360” meets “Quality 360.” This paper will explore the unique considerations of doing so, what achieving this alignment requires, and what to expect after embracing this approach.
DevOps for Salesforce: Unique considerations
Salesforce is a living, breathing entity that evolves constantly. Its evolution happens on its own and in unique ways for each organization it serves, as platform owners continue to build new processes and customize their Salesforce environments. All of these changes amount to frequent release cycles that make regular testing critical.
The most advanced organizations aim to balance speed and quality throughout these releases with a focus on increasing innovation velocity (as measured by reducing the lead time for change and increasing deployment frequency), all while maintaining reliability and trust (as measured by reducing the change failure rate and mean time to recovery).
DevOps is the prime way to accomplish this balance, which makes it crucial to align Salesforce testing to DevOps release processes. However, doing so isn’t cut-and-dry. Considerations include:
- Complexity and scale of ecosystem: Salesforce environments get extremely complex very quickly, and the sheer size of the Salesforce partner ecosystem only compounds this complexity. Additionally, because Salesforce itself manages the infrastructure, traditional DevOps tools and techniques focused on this area don’t offer as much value.
- Types of users and customizations: Both IT and business users own Salesforce, which allows for low-code, or even no-code, development on the platform. The presence of business users and no-code customizations turn more traditional development and delivery processes on their heads. It also means both teams must find an environment in which they can easily collaborate to keep each other aware of changes.
- Frequency of changes: Regular changes coming from Salesforce, its partners, and within the organization mean the environment is constantly in flux, and even seemingly small changes can make a big impact. This frequency requires test automation to truly keep up with the pace of change —but the regular changes to the Salesforce platform itself can easily break automated test cases.
An environment with so many moving pieces and can prove quite unstable to a traditional DevOps approach. As a result, aligning Salesforce testing with DevOps release processes requires a tailored approach to maintain focus on the right areas, encourage collaboration between IT and business users, and ensure that test automation can withstand platform changes over time. Otherwise, teams have to regularly maintain and re-build test scripts, which chips away at the ability of DevOps to balance speed and quality.
What you need to align Salesforce testing with DevOps
Given the unique considerations of DevOps for Salesforce, aligning Salesforce testing with DevOps release processes requires a different approach. Two key areas of focus to achieve this alignment include:
Bringing together IT and business users to work toward a common goal
First, organizations must unify IT and business users to work toward a single goal of what the Salesforce ecosystem should accomplish and potential business risks in pursuit of that goal.
Getting this alignment early is critical to ensure that all key areas of risk are covered and that there’s clarity around who will own which pieces of the testing process. Critically, organizations cannot isolate the testing process to one group or cleanly split testing so that each group handles their own needs. Rather, IT and business users must work together, since they have complementary areas of expertise: One group knows test automation well (but has a low knowledge of Salesforce and its flakiness), while the other group understands the Salesforce journey and key business needs (but doesn’t have experience with test automation).
Encouraging collaboration between IT and business users helps organizations achieve change faster and with more stability because of the groups’ respective understandings of the Salesforce environment.
Speeding testing processes through automation
Second, organizations need a way to speed testing processes through automation rather than running manual regression testing.
Manual regression testing typically creates bottlenecks for delivering new releases given the fast pace of change for most enterprise Salesforce environments. Introducing test automation can help alleviate this burden—if it’s done correctly.
Specifically, organizations must stabilize test automation so that it doesn’t break down when Salesforce releases regular updates to the platform. They must also make this automation accessible to both IT and business users to facilitate the necessary level of collaboration between the two groups.
Importantly, the only way to achieve this level of collaboration is to introduce tooling that’s friendly to both IT and business users, which typically means it supports a no-code environment. Additionally, this tooling should focus less on infrastructure, since Salesforce handles this piece of the DevOps equation. This leaves organizations with three choices:
- An off-the-shelf product from an independent software vendor: A solution that supports test automation through a “click not code” environment and offers a high level of stability because the software vendor accounts for changes from Salesforce to help ensure that tests don’t break as new releases come to market.
- A custom solution from a systems integrator: A full service solution from a third party expert that covers the build of code-based tests; a continued relationship with the system integrator that offers stability, but requires time and money to regularly update tests to account for ongoing changes.
- An open-source test automation framework: A solution for teams with enough engineering resources to implement and maintain a test infrastructure, with stability against changes only coming from ongoing maintenance led by in-house resources.
While each approach has its pros and cons, for most organizations, the most stable solution that offers consistent quality and helps maintain the necessary speed is an off-the-shelf product. This often is the best choice because the no-code environment helps bring IT and business users together, and the stability provided by the platform ensures that tests don’t break as new changes get released.