Transcripted Summary
In our next section, let's look at some key focus areas for testing a SaaS, Software as a Service, application. So let's go.
When you build on top of a SaaS or PaaS, Software as a Service or Product as a Service platform, there are many pre-built and tested pieces offered to the customers.
Some of these could be a fully operational database, back-end and front-end APIs, security and authorization, and components such as search, list views and admin console.
Some platforms like Salesforce, Oracle, and ServiceNow also offer advanced capabilities like monitoring and UI/UX design language for the platforms.
From a tester's lens, it is very important to understand the difference between all of these and the customizations built on top of the platform, as this will define the scope of testing and automation for your situation.
Let's go a little deeper into the understanding of what is a standard offering and what are customizations on the Salesforce platform.
# Standard vs Custom Salesforce offerings
Basically, when you get the Salesforce license, not only do you get the access to the core platform, but also some key functionalities like saving records, layouts, and user personas.
These are termed as standard offerings and then, you actually build on top of the Salesforce platform with customizations like - let's say - a customized webpage to ensure that your business needs are met.
These two play hand in hand, just like these two friends on the beach, and provide a seamless customer experience.
Let's look at a few examples of Standard offering versus Customizations.
We have a small table for you over here with three column - field type, "what is it?", and an example.
First we have the identity. It's a 15-character. case-sensitive field that's automatically generated for every record.
Think of it as an identifier for an item in the database.
You can find the record's ID in its URL, and let's say, for example, an account ID looks like the one we have over here.
The second is system fields - read-only fields that provide information about the record from the system, like when the record was created or when it was last changed or modified.
CreatedDate, LastModifiedById and LastModifiedDate are some examples there.
The third row stands for the name - all records need names, so you can distinguish between them.
You can use text names or auto-numbered names that automatically increment every time you create a record.
A contacts name can be Julie, or so on and so forth. A support case's name can be CA-1024. Those are some examples for the name.
Then there are custom fields - fields you create on standard or custom objects are called custom fields.
Let's say you create a field to store the birthday of a certain contact - that's a custom field.
Please note: identity, system and name fields are standard on every object in Salesforce.
Thank you. I hope that you are having as much fun learning from this course as we are having making this for you.
# Salesforce Test Automation
With that note, let's look at some additional considerations for Salesforce Test Automation.
First and foremost, let's look at the two flavors of Salesforce UI - the classic on the left, and lightning UI on the right.
While testing and automating Salesforce scenarios, you might come up with these two flavors of the Salesforce UI and UX, or user experience.
Lightning was first introduced to Salesforce's customers as a Beta framework for building user interfaces in 2015.
By 2018, it had expanded into a full fledged, deeply customizable interface that could replace the classic Salesforce UI.
Today, all of Salesforce's new features are built for the Lightning UI.
Salesforce Classic exists largely in an as-is state for those companies that cannot yet make the switch.
This may be due to customized interfaces, workflows, or just the general difficulty of making a big switch with thousands of users.
Prior to around 2018, it made sense for smaller businesses to stay away from Lightning, since the feature set wasn't as fully formed as what you could use via classic.
That's becoming less and less the case as most key features have now migrated to Lightning from the Classic interface.
On that note, let's look at the other key piece for Salesforce Test Automation - the Lightning Web Components.
Lightning Web Components are an updated web standards based framework for creating lightning components on the Salesforce platform.
Lightning Web Components utilize standard technologies like CSS, SGML, and updated JavaScript without requiring a set framework, incorporating the latest innovations in JavaScript, including shadow Document Object Model (DOM), custom elements and web components.
ECMAScript 7 is specifically the updated JavaScript language used over here.
# Test strategy for Salesforce
Now that we have a good understanding of the nuances of Salesforce Test Automation, let's have a quick word around test strategy for Salesforce and similar SaaS applications.
First and foremost, you should understand what should be tested on the UI layer versus the API layers.
Interestingly, a lot can be tested on these applications better at the API layer, and not every test deserves a UI automation counterpart.
Secondly, kindly consider all the user personas for your application under test on a multi-tenant Salesforce application.
This could include admins, sales representatives, operational team members, engineers, and other users.
The third is around the test data.
As part of a test strategy, kindly ensure that you are considering the data set up, cleanup and archival.
Last, but obviously not the least, measurement of KPIs and key success metrics for your testing and automation efforts is paramount to the test strategy.
