Testing Practices in Salesforce.com

Testing in Salesforce Applications is different from Testing the Applications on other platforms.

When Testing the Web Applications and Standalone Applications, we do not need to check / perform Configurations / Settings and all. But, in Salesforce we should be aware of the Salesforce configuration/ Administration settings to test the requirements.

As Salesforce testing is slightly different from other (Web, Mobile) testing, Web or Mobile Testers can test the applications without the domain knowledge, but Salesforce Testers are not supposed to test a Salesforce application without Salesforce knowledge. So it would be better if the Salesforce tester has the basic knowledge on Salesforce to understand the functionality. They should have clear knowledge with standard Salesforce functionalities such as creating Fields, Objects, Workflows, Approval Process, Queues, Custom Settings, Web-to-Lead, and Web-to-Case and so on.

The below is the list of Salesforce testing elements we are covering in this article:

We have to log into Salesforce.com before starting the testing.

For example, to test ‘Lead’ object fields, a new tester might navigate through Lead Tab -> Click “Quick Access Menu” -> View Fields.  This action will take us to ‘Object Definition Page’– which is not the desired one. So, this is not a right way to verify the fields, but you have to check the fields in UI page.

During testing, we have to think like an end-user, and below is the right way to test fields.

Assume the following scenario:

Scenario: A financial organization has decided to assign an equal number of incoming leads to each advisor. The Leads are created either manually or thru Web-to-Lead forms. So the organization used some formulas and 4 Queues TEAM A, TEAM B, TEAM C and TEAM D. Now, an equal number of leads are randomly assigned to the appropriate advisors based on the queue.

In order to test this scenario, the below is the right navigation rather than directly going through Setup -> Manage Users -> Queues to check the queue.

A university maintains a website for their students. Every year, the University may add some new programs and remove some of the existing programs from “Program” list from their site. So they would like to do that change via configuration instead of customizing the code. They have implemented this functionality via custom setting.

Now the university wants to include a new program “Music (BFA)” to the “Program of Study” to their site.

Here, the verifying the values in custom settings is not enough. It should be verified by the newly added value in “Program of Study” picklist at the University website.

Many of us know that open tasks are available under “Open Activities”. What about the closed task? Where does Salesforce show the Closed Activities?

A task can be closed either manually or automatically. In either way, we can find that closed tasks are under “Activity History” related list as below.

Here are a few general Guidelines to be followed for Testing in Salesforce scheduled jobs and Time dependant workflow:

Scheduled Jobs are used to perform specific action (Apex Class) at a specific time. It may be recurring at regular intervals. After the job is run, we can verify the Expected Result from the specified record.

Here, we have to test the following scenarios:

A scheduled job should pick the Account records which are in Open Status and change them to Active Status.

After the Status is changed, a task is created for the same updated records with a future due date.

Example:

Status   (Existing)                        – Open

Status   (New)                             – Active (Status change is performed by the scheduled job)

Due Date for the task creation    – Status change Date + 5 days

It is implemented by using the Apex Class, Scheduled Job and Time-Dependent Workflow.

To test the above scenarios we have to follow the below steps:

In order to test this scenario, we need run the code that implements the job manually. So, we can get the code snippets (from the development console or IDE ) to update Account record which are in Open Status into Active Status.

Then go to Developer Console ->Debug  -> Open Execute Anonymous Window.

Paste the snippet in the window & execute it. The status of this execution would be success.

Now, go back to one of the Account objects and verify the Status change in that particular record. The “Status” would have been updated as “Active”. This is the functionality of the scheduled job, but here we tested manually.

After the Status update, a task would be created with a future due date, and It will be waiting in the Time-Based workflow queue to deliver it until it meets the scheduled date.

To verify it, go to Monitoring (Administration Setup) -> Time-Based Workflow and search for that particular record.

Task would be created on the particular day when TODAY equals to the Scheduled Date.

Once the task is created on the Scheduled Date, there is no task waiting at the workflow queue for that particular account record as below.

Lead is a person who is interested in doing the business with the organization such buying a product and service. Leads can be captured through the typical marketing campaigns or through the company websites. Once the lead enters their information on the website, the lead record is created automatically in Salesforce with the respective data from the website. This is the functionality provided by the Salesforce and there is no need of installing any additional applications.

Web-To-Lead Testing

The purpose of this section is to test the web-to-lead functionality and to achieve this by following the below steps.

The customer information is entered from the organization’s website by the customer.

Once the form is submitted, the following actions would be performed.

• Lead record is created in Salesforce with the information entered on the website Lead form.
• The Lead record will be automatically assigned to the user who is set as Default Lead Creator in the Salesforce.com setup.
• The customer would have received the acknowledgment email from Salesforce.com.
• The Default Lead Creator will also get an email that notifies the lead assignment.
• A task would have been created for the confirmation of the acknowledgement sent to the customer and it will be closed automatically once the acknowledgement email is sent.

The lead is created in Salesforce and it  will contain all the information entered in Web-to-Lead form. The data can be seen here: Leads -> My Unread Leads (List View).

The Lead Owner would be match with the Default Lead Creator in the Lead record.

Here the ‘Default Lead Creator’ is highlighted in Web-to-Lead Setup.

The user highlighted above will receive an email to notify the lead assignment as below.

In Addition, the customer would have received the acknowledgment email from salesforce.com.

A task would have been created and the task can be verified on Lead record’s ‘Activity History’ Related List.

The web-to-lead functionality is tested by verifying all the actions mentioned above.

Summary:

The testers can do Salesforce.com testing for fields, Queues, Custom Settings, Closed Tasks, Scheduled Job, Web-To-Lead & Time dependant Workflow by following above ways/steps. For Web-to-Lead, in Professional, Enterprise, Unlimited, Performance, and Developer Edition organizations, you can capture up to 500 leads in a 24–hour period. If your organization exceeds its daily Web-to-Lead limit, the Default Lead Creator (specified in the Web-to-Lead setup page) receives an email and the additional requests are stored in a pending request queue. So the Leads from this queue would be created by the next day.