Defining the Approach

Sales Cloud and the Salesforce Customer 360 platform have a lot of capabilities and can seem quite complex. It can be daunting to work out how to approach the customizations you need to implement, from ideation through to successful deployment to the end users. Some changes to the platform can also be very simple, so it is easy to dive right in and only realize the consequences later.

In this chapter, we’ll start by learning about Salesforce’s application life cycle management (ALM) to give you a framework you can use to think about the stages of your implementation. With this understanding, we’ll explore the topics you need to understand and make decisions about at the start of your implementation before any building work is carried out. We’ll look at the characteristics of two commonly used development methodologies, Agile and Waterfall, and how these are applied in practice. We’ll also learn about the environments Salesforce...

Supporting tools and information

To complete this chapter, you’ll need to have knowledge of the development methodology and the tools that are used to support it. You must also know what your Salesforce edition is and how to use Sandboxes.

Salesforce ALM

ALM describes how the life cycle of a business application such as Sales Cloud is managed – that is, how an idea or requirement gets defined, built, tested, and delivered. It is a combination of people, processes, and tooling. Having a structured approach to delivering your Sales Cloud solution provides predictability and repeatability in a way that enables teams to work together to deliver appropriate high-quality solutions. The following diagram shows the ALM. This diagram is based on the Salesforce ALM process document on Trailhead but we have expanded it beyond deploying the solution:

Figure 2.1 – The ALM process

Figure 2.1 shows the key stages of the life cycle at a high level. Within each stage, there are several other well-understood activities and actions. Although testing is listed as a separate stage in the preceding diagram, we will discuss why it can be beneficial to incorporate testing into the build stage in the...

Salesforce environment strategy and DevOps tools

In this section, we will look at the development environments and tools that Salesforce provides to support the ALM of both low-code and pro-code development. Salesforce provides two types of environments: Sandboxes and Scratch Orgs. They provide these so there is no reason to carry out customization and development in your Production Org, which is considered a bad practice.

We will start by exploring the Salesforce Sandbox development environments.

Salesforce development environments – Sandboxes

In this section, we will explore the Sandbox development environments that are available for your Sales Cloud development. We’ll review Scratch Orgs in the Salesforce DX (SFDX) section. It is bad practice to make certain types of changes directly in your production Sales Cloud environment. Although many Sales Cloud changes seem quick and easy, they can harm Users and integrations if they are not appropriately planned and...

Developing a testing approach

Testing is the third stage of the Salesforce ALM. In this section, we’ll review the planning that is required to set up your testing approach. In Chapter 8, Executing Testing, we’ll expand on the content in the section and look at the specifics of the functional testing phases that we’ll introduce in this section. We’ll also consider the practical aspects of testing. We’ll start with a foundational understanding of why testing is important.

Why is testing important?

Testing is part of any quality assurance process, which aims to prevent defects and errors in software solutions. Testing confirms that the functionality that’s built delivers the requirements specified and will be an important part of your implementation delivery. This ensures that the solution delivers on stakeholders’ expectations and that it can be trusted. A solution that has errors and defects will quickly be mistrusted and abandoned...

Testing low code versus pro code

One of the key benefits of the Salesforce platform is its declarative, low-code tools. The declarative approach makes some changes, such as adding fields, really simple and almost trivial. With this quick pace of change, it is easy to get swept along and forget that any testing is required. In this example, the field itself is only one element. It needs to be on the correct page layouts, be visible and editable by the right Users, and be checked to ensure that if it is a required field or has validation, existing processes do not break. These other elements can be easily overlooked but have significant security and integration implications. No system-enforced process requires declarative changes to be tested. However, as the capability of the low-code tools increases, as seen with the automation capability of Flows, there is a move to introduce testing options. Now, you have options to debug your Flows and for some types of Flows, you can also create...

The impact of deployment methodology and environment strategy on testing

In the previous sections, we explored common development methodologies and the environment strategy that’s used for Sales Cloud projects. The approach taken here has an impact on how testing can be incorporated into the development life cycle. Let’s explore how each has an impact:

• Development methodology: Agile and Waterfall require different testing skills. The difference between working with an Agile, rather than Waterfall, methodology is that the focus is on face-to-face communication rather than extensive documentation. This means there is less documentation for testers to work from. Documentation is required. Agile can be harder for testers as there is a need to continuously adapt. Testers on Agile projects fulfill a range of roles, including attending sprint planning, estimating tests, writing test cases, and attending reviews.
• Environment strategy and management: Not having dedicated...

Types of testing

In this section, we’ll review the terms and types of testing that are most commonly used in Salesforce projects to give you the language to use when you talk about testing. You may find that other terms are also used across the software testing industry.

The following are the areas of testing you should be aware of:

• Functional testing: This is a type of testing that is used to confirm that software performs the function specified in the requirement.
• Non-functional testing: This is a type of testing that verifies factors that impact the end-user experience, such as performance, page load times, and security.
• Unit testing (functional): This is carried out by the person developing the functionality. Its purpose is to confirm that the functionality works as expected. Unit tests should be carried out to confirm that the functionality that’s been built performs the expected actions.
• Quality assurance testing (functional): This is carried...

Test strategy versus test plan versus test cases

In this section, we will get to know the artifacts that provide structure and consistency to your testing approach. These documents or artifacts capture the why, what, and how of testing. There are three levels of testing documentation: test strategy, test plans, and test cases. Here, the test strategy provides an overarching view of testing, and test cases provide the detail required for execution. We’ll start by exploring the content and role of the test strategy.

Test strategy

A test strategy is a high-level document that summarizes what and why software testing is carried out in an organization. It provides a framework that is platform and technology-agnostic. Each implementation project should use this framework to define a testing plan for their implementation that is tailored to the platform, technologies, scale, and complexity they have.

Defining a test strategy before your project starts illustrates that quality...

Change management and training

In this section, we’ll explore what’s meant by organizational change management. This fits within the adoption phase of the Salesforce ALM. First, we will learn about what is meant by change management. We will explain the role that training has within change management, how it prepares your stakeholders, and its role in adoption. Let’s start with change management.

What is change management?

Organizational change management is the discipline of taking people and organizations through change. People, and consequently organizations, can find it difficult to embrace change, which can impact the organization’s ability to survive and thrive. Due to its importance to business success, there is a lot of academic research on this, and strategies have been developed to increase change management success rates. The types of organizational change have been categorized, the challenges have been understood, and an established set...

Planning your training

In the What is change management? section, we learned that training is an essential component of organizational change. Training provides an opportunity to tell Users, and other impacted stakeholders, the benefits of what is being delivered, as well as provide the knowledge and the skills Users need for the tasks they will be required to carry out in Sales Cloud.

If your organization has a learning and development team, then you will want to engage with them to understand if there is any institutional knowledge, processes, or tools that you can adopt that will accelerate your training development and smooth User transition.

We will start by exploring the different types of training so that you understand the options that are available as you put together a training plan.

Types of training

In this section, we will go through each of the types of training that are commonly used in Salesforce implementations. We have used the terms that are most often...

Summary

In this chapter, we started by learning about the Salesforce ALM, which provides a framework for how we develop our Sales Cloud solution. We reviewed the two customization approaches, low code, and pro code, and explored the different delivery methodologies you can follow.

We then went on to learn about the environments Salesforce provides for development and the tools that are available to move the functionality you have built between these environments. With this foundational understanding of the tooling available, we considered how to develop a test plan for our solutions, something we’ll build on in Chapter 8 – Executing Testing. We’ll continue to explore the importance of change management and training in taking your users on the journey with you to ensure overall implementation success. We’ll expand on what we have covered in this chapter in Chapter 9 – Executing Training.

In the next chapter, we’ll take a detailed look...

Further reading

Sandboxes

• Sandbox Licenses and Storage Limits by Type:

  https://help.salesforce.com/s/articleView?id=sf.data_sandbox_environments.htm&type=5

SFDX

• App Development with Salesforce DX:

  https://trailhead.salesforce.com/content/learn/modules/sfdx_app_dev/sfdx_app_dev_setup_dx

Agile

• Agile Manifesto:

  https://agilemanifesto.Org/

• Agile Principles:

  https://agilemanifesto.org/principles.html

DevOps

• For more information about the history and principles of DevOps, see:

  https://www.ibm.com/topics/devops

• Scale Testing:

  https://architect.salesforce.com/well-architected/trusted/reliable#Scalability

Change management

• What is Organizational Change? Article Harvard Business School:

  https://online.hbs.edu/blog/post/organizational-change-management

• 10 Change Management Models:

  https://whatfix.com/blog/10-change-management-models/

Training

• Sandbox Licenses and Storage Limits by Type:

  https://help.salesforce...