Transcripted Summary
Now that you know how to write test cases, how the autowaits work or the magic of autolocators, let's sum it up into a holistic Salesforce testing strategy.
We'll look at the scope definition, what not to test, and some learning resources to continue your learning journey.
Let's begin with the first one.
# Defining the Scope of Test Automation
Let's define some of the key elements for the scope for test automation.
First and foremost, we have data management.
As we have seen earlier, Salesforce implementations can have various environments and sandboxes.
Now that should be coupled with the data that we create on these various environments and sandboxes for our testing, but also carefully purge the data as we move through the cycles of deployments.
Second key ingredient is the users and roles.
As we have also seen earlier, Salesforce can not only be used as a CRM or for sales, it also has these other pillars such as community or omnichannel or service and support.
Users and roles should be carefully considered for these various pillars, and your test strategy should have specific elements and attributes to test out all the users and roles within scope, as defined by the business functions.
Last but not least, we have integrations and Appexchange.
Salesforce is a very versatile platform and it could have integrations and Appexchange products installed on top of the core platform itself.
In your case, it could be Velocity, CPQ, and the other products.
These should be carefully considered for your test strategy, because when the users use your application, they're bound to encounter some issues, not just on the code platform, but through the integration and Appexchange products as well.
Therefore, you must consider these points when you define and design your test strategy.
# What not to test
Having that said, let's move on to the next section of what not to test.
Now, this is very interesting.
While we are saying here - "don't test out the six key elements" - I would highly encourage you to go a little deeper and understand why you should actually not test them or test them based on your actual requirements.
Navigation between console tabs and sub-tabs are part of the standard Salesforce UI, so you need not explicitly test them.
Utility bar recent items, history notes, etc, are key pillars of the Salesforce UI as well, so you need not assert and verify these elements.
Same goes for chatter interactions, unless you have customizations built on top of it.
Salesforce related list, View all links, are these other UI components which you need not exclusively test and assert.
List view filtering and sorting is also provided by the Salesforce platform, and so is changing between apps and tabs by the AppLauncher.
As I said, these are core Salesforce UI elements, so you need not test them explicitly or assert for them when you go through these UI interactions, but please do consider the customizations that you and your dev team have done on top of your Salesforce implementation.
If they impact any of these elements, please go ahead and do test them.
Now that you know what to test by the scope and what not to test, let's sum it up in one picture where Quality meets DevOps.
What we are trying to portray over here is the Application Lifecycle Management for your Salesforce application.
At the center we have the VCS, version control system, as a source of truth.
In your case, it could be Git or GitHub or Bitbucket.
On top of that, we have the layers, or the cycle of planning the release, developing it, testing it out, the build release cycle, test release, and then the actual release into production for the end users.
This lifecycle is supplemented by the six other points on the outermost periphery of the circle.
CLI for integration with third party editors, scratch orgs, continuous integration via test automation, continuous delivery via build automation, sandboxes for performance testing, non-functional tests, UAT and staging, and last but not least, packaging to streamline delivery to prod.
Keeping all these elements in mind, you can construct one holistic test automation strategy so that you can actually deliver quality for your end users and your teams. Thank you.
