Salesforce Testing Tips & Best Practices

“Do what you do so well that they will want to see it again and bring their friends.”

This popular quote from Walt Disney resonates very well when it comes to establishing a benchmark statement for customer satisfaction. As a Salesforce consulting firm, our main focus is on customer satisfaction and designing solutions that will make our clients’ lives easier. To achieve this, it is imperative to deliver high-quality software products.

Software Testing to Ensure Software Quality

Software testing is an important process for gauging the quality of a software product. There are several types of testing that should be carried out on software development projects. Each type of testing has a certain “objective” that defines the correct expected behavior the test is aiming at, so that any incorrect behavior (an observed failure) can be identified.

What is Salesforce Testing?

Normally, Salesforce testing of Apex Classes and Triggers is done by the developers themselves as it is necessary to write the test classes to move the code from sandbox to production. Developers must ensure that their code coverage is minimum 75%. But, the functional testing is performed by the Quality Assurance (QA) team to boost the quality of application.

As with any other Software Delivery, the following six types of functional testing can be implemented in Salesforce to ensure the quality of the end product. Those tests are: unit testing, functional testing, systems testing, regression testing, system integration testing and user acceptance testing.

1) Unit Testing: Unit testing is the process of testing each unit of code in a single component. This testing is carried out by the developer as the component is being developed. Unit tests allow developers to constantly ensure that a unit of code does what is intended even as connected units change.

For example: Testing a particular section on a page layout. (Object in Salesforce)

 2) Functional Testing: Functional testing addresses issues surrounding the correct implementation of functional requirements. Also referred to as ‘black box testing’, this type of testing requires no knowledge of the underlying implemented code.

For example: Testing all the sections of a record on a page layout. (Object in Salesforce)

3) Systems Testing: During the system testing the team executes tests from an end-to-end perspective System testing helps examine the correctness of the business, functional, technical, and any non-functional requirements of the application.

For example: Testing how different objects interact with each other in an application and how business processes are handled.

4) Regression Testing: The main objective of regression testing is to verify that modifications in the software or the environment have not caused any unintended adverse side effects and that the system still meets its requirements.

5) System Integration Testing: System integration testing is a process that evaluates the software’s interoperability and cooperation when integrated with other systems or software.

For example: Testing an application when it is integrated with external systems and software.

6) User Acceptance Testing: It’s the last step in the QA testing phase. Interact with the system, ensure that it does what is expected and is easy to use. The customer is usually responsible for performing these tests.

For example: The product owner itself logs into the system and tests the system as an end user to validate the business scenarios before releasing it to production.

Best Practices for Salesforce Testing

With this prelude, let’s further discuss some of the best practices that can be adhered to across the different stages of Salesforce testing for a successful implementation.

Testing should start early in the Software Development Life Cycle

The test team should be involved in the project from the very beginning. Not only will this help testers become more familiar with the software and requirements, it will also benefit in anticipating future problems at a significantly lower cost. This has been proved by many studies which indicate that the average cost to repair the bug increases with each advancement in the SDLC. Another advantage of having the test team start early in the Life Cycle is that the risk of having a short time for testing is greatly reduced. This assists the test team to increase their test coverage and types of tests performed. Also this gives a chance to confirm with the client about the requirements that are not related to that are not related to the project goals. It is significant that these requirements are identified and clarified with the client if it is really necessary.

Test Case Walkthrough Sessions

Once the test team is involved during the early stages of the project, it will have ample time to prepare quality test cases and increase coverage. After the test cases have been prepared, a formal walkthrough session should be arranged in which the author of the test cases demonstrates or explains the test cases to the concerned stakeholders including the developers. The walkthrough session will help in ironing out ambiguities in interpretation caused by some general terms or discover any missing requirements. Test Cases should cover all the aspects of the system and business workflows without any assumption. Sharing the test cases with the dev team before the implementation phase can help developers to think outside the box and evaluate more chances of failure in their code.

Thorough Unit Testing

Before the developers hand over the code for testing, it’s best practice for them to unit test the code they have developed. This will ensure errors to be discovered during the early stages of the development life cycle. Along with that this will help in lowering the testing / retesting and the bug fixing costs. Another advantage of performing the unit testing is it helps in building code that is reusable and easy to debug.

Additional Key Testing Practices

Manual Testing in Salesforce is performed by the testing team and includes testing like the functional testing, integration testing, regression testing and system testing. To ensure a quality Salesforce implementation, there are some key practices that the tester must observe to namely, but not limited to:

1. In a multi-environment setup before starting on with testing confirm with the development team that the changes and configurations have been deployed the sandbox that you are starting to test in.
2. Always ensure to test with the correct logged in profile as stated in the requirements and test cases.  Never assume that system will work the same and as expected, as when you are testing with the system admin profile or any other profile that has full rights.
3. To mitigate any risks of the implications involved in implementation of integration of Salesforce with legacy system for import of data, the testing team effort should be concentrated on the following areas: 
   • Source to target mappings for each category of data
   • Destination i.e. Salesforce system data requirements such as the field names, field type, mandatory fields, valid value lists and other field-level validation checks.
   • Source and target system connections from the migration platform.
   • Errors during the migration should be identified, investigated, and their disposition agreed.
   • Validate that all new workflow, assignment, approval rules and email notifications are working correctly.
4. Validate who sees what implementation (ie. the security and access to various objects, records and fields have been acceptably implemented as per the requirements). This can be configured and implemented via Profile Object Permissions (OWD), Record Types, Page Layout Assignments, Organization Wide Defaults and Field Level Security.
5. In case Manual sharing is included in requirements, run tests to ensure the records are correctly shared and there is no impact to the overall Organization Wide Defaults visibility of the records.
6. To validate Reports and Dashboards implementation some key areas that should be the focus of testing are:
   
   • Report Type: A report type defines the set of records and fields available to a report based on the relationships between a primary object and its related objects.
   • Reports: A report returns a set of records that meets certain criteria, and displays it in organized rows and columns. Test a report to validate the data has been filtered, grouped, and displayed graphically as a chart as per the requirements.
   • Dashboards: Administrators control access to dashboards by storing them in folders with certain visibility settings. Each dashboard has a running user; whose security settings determine which data to display in a dashboard. If the running user is a specific user, all dashboard viewers see data based on the security settings of that user—regardless of their own personal security settings. For dynamic dashboards, you can set the running user to be the logged-in user, so that each user sees the dashboard according to his or her own access level.
   • Access to Reports and Dashboard Folders: Reports and Dashboards are stored in folders, which control who has access. Folders can be public, hidden, or shared, and can be set to read-only or read/write. You control who has access to its contents based on roles, permissions, public groups, and license types
     
7. Defect Logging is an integral part of testing and the testers must ensure that any defect logged should be easily comprehended by the developers. This will reduce assignment of the defects back and forth and quick turnaround. To ensure the defects are logged in best possible way the following tips can prove handy:
   • Ensure the system behavior is accurately depicted, the actual output and the expected output that was seen to constitute the defect. Clear and simple language should be used.
   • Ensure that you report steps to reproduce that need to be followed in enough detail. Using these, will help any developer to replicate the erroneous system behavior.
   • Ensure that you report all the necessary information such as Sandbox logged in, profile used, requirement reference on which the error was seen, etc.
   • Attach snapshots of the error screen to support your claim of error in the system.
     
8. Before releasing the software to the production User Acceptance Testing (UAT)  has to be performed that takes the final call whether the solution meets the requirements and is fit to be released. To ensure a successful and a quality User Acceptance Testing users should be identified who would carry out actual testing. The users can be of different profiles representing different functional areas of the system. The testing team should record and document each issue flagged by users and triage them for a resolution.

Given how essential software has become to the world, it’s hard to dismiss the importance of software quality. Adhering to the best practices and key points discussed above is a step in the right direction.