Skip to content

Latest commit

 

History

History
92 lines (64 loc) · 7.94 KB

TestingBeforeDeployment.md

File metadata and controls

92 lines (64 loc) · 7.94 KB
title nav_order
Testing Before Deployment
4

Testing Before Deployment

Summary

When administrators are deploying new features to their production environment, an important stage of the Software Development Lifecycle is to test the functionality of new features before they are deployed. Testing helps ensure that the features that you build meet the required standards and specifications. Identifying defects and issues before the software is released helps to improve overall quality. This process usually involves an end user of the new feature creating dummy data and testing the functionality of metadata in a Sandbox Environment. For more information on Sandbox Environments, refer to this article. Regression Testing is also essential to ensure existing features are still working when new features are developed.

Use Cases and Test Steps

Now that you have understood the importance of testing new features before deployment, let’s dive into what the process should look like. A good place to start is by noting the different business use cases that apply to end users, with respect to the new features. The next stage is to have an end user go through the different use cases in a sandbox environment and provide feedback. These phases enable administrators to identify gaps in their build before they are deployed to a production instance. They also help the organization by identifying edge cases and bugs that should be fixed before deployment.

What should my test scripts look like?

When creating test scripts, it is important to have context on who your end user is. Are they tech-savvy? Have they been working with Salesforce for over 10 years, or are they a beginner? Once you have an idea of who your target end user is, you can begin creating “test scripts” for them.

Here is a list of important features that every test script should have and some tips on how to create them (please note that this list is not exhaustive, and can vary based on your organizations’ need):

  • Business Use Cases:
    As an end-user, how am I going to utilize this new feature/function? What are my business goals as an end user and how does it relate to this new feature/function in the build?
    A good framework to follow is: As a ____(Salesforce Profile) user, I would like the ability to ___(business use case), so that I can ____(pain point eliminated with feature). An example is: As a fundraising user, I would like the ability to automatically convert Leads to Contacts if they respond to my email outreach, so that I can save time on administrative tasks.

  • Steps:
    As an end user, what steps do I need to follow to utilize this new feature/function?

    In this section, you should outline the step-by-step instructions on how to utilize the new function you have built for the end users. It is always a good idea to provide a visual example for each step, such as a screenshot or a video recording. An example of test steps is as follows:

    • Step 1: Create a new lead with your email address
    • Step 2: Send an email to the lead using Salesforce
    • Step 3: Check your inbox for the email and respond to it

  • Expected Behaviour:
    After following the steps outlined in the test scripts, what results should I expect to see as an end-user?

    In this section, you should outline the expected behavior that end users should experience after following the step-by-step instructions you created. This section is important as it creates a basis for end users to provide feedback on the new feature/function that you have built.

  • User Comments and Progress:
    Finally, it is important to have a section where users can input their feedback, provide comments on what they are experiencing during the testing phase, and sign off on the build if all is well.

Here is a link to a template that you can use for your organization.

What if I don't have an end user that is available to test the functionality?

In the event that you do not have a team member or end user that is able to test the functionality of new features before deploying, as an Admin user, you can log into Salesforce with a user that has the same profile as the end user that you are building for. Then, go through the test steps as if you were an end user.

Testing with permissions in mind

Having end users log in to the sandbox or using the “Login As” feature is critical as it allows you to test that the correct permissions and access have been applied. If you only test logged in as an administrator, you may hit some unexpected access issues or errors when your feature goes to production.

Design with Testing in Mind

Before you start building your new feature, think about the testing you should conduct. In tandem with determining the requirements for a feature, determine the corresponding test scenarios and write out your test scripts. This should include both positive tests (the “happy path” and what should result), and negative tests (what happens when a user behaves unexpectedly or inputs invalid data). Negative tests could include:

  • Leaving a required field blank
  • Entering letters in a field that only accepts numbers
  • Exceeding field length limits
  • Entering data that violates an existing validation rule
  • Intentionally hitting fault paths in a flow

Key Takeaways

  • Testing before deploying a change set can save your organization time and resources by identifying bugs in a sandbox environment, and rectifying them before a deployment to production.

Further Learning & Resources

Author(s)

Suraj Varma
Ashley Vogel
John Sim

History

First Published: 2024-09-27