Software Testing – A tool for better Software Quality

Software testing is one of the important processes for analyzing the quality of a software product. There are different types of testing that should be done on software development projects. Every kind of testing has its certain “objective” that underlines the correct objective the test is aiming at so that any issue or error can be traced easily

What is Salesforce Testing?

In salesforce, the testing of Apex Classes and Triggers Salesforce is basically performed by the developers themselves as it is required to write the test classes to move the code from sandbox to production org. The developers should make sure that the code coverage is a minimum of 75%. To maintain the quality of product the functional testing should be performed by Quality Assurance (QA) team.

In every type of software product, the following six types of functional testing are also a must in Salesforce to make sure that the quality of the end product is up to the expected mark. The following are some of the common functionality tests that are performed in salesforce testing.

1. Unit Testing: It’s the process of testing each unit of code in a single component. This testing is mainly performed by the developer as soon as the component is being developed. Unit testing allows the programmers to constantly monitor and to ensure that a unit of code is performing as per expectations.

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

2. Functional Testing: Functional testing is a type of black-box testing to verify the correct implementation of functional requirements. This type of testing is performed by Testers and requires no knowledge of the implemented code.

   For example: Testing all the sections of a record. (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 the functionality and flow to know how different objects interact with each other in an application and how business processes are handled
4. Regression Testing: The purpose of regression testing is to verify that the whole system software or the environment have not caused any severe side effects and that the application or the system still meets its predefined requirements.
5. System Integration Testing: System integration testing is a process that evaluates testing of the whole system which is composed of many sub-systems to ensure that all software module dependencies are functioning properly.

   For example: Testing an application after integrating the external systems and software.

6. User Acceptance Testing: User Acceptance Testing (UAT) is the last stage of any software development life cycle where the actual users test the software to verify that the application is able to carry out the required tasks it was designed to adherence to the customer’s requirements.
   For example, The product owner tests the system as an end-user to validate the business requirements before releasing it to production.

Best Practices for Salesforce Testing

Let’s discuss some of the best practices that can be performed across the different stages of Salesforce testing for a successful implementation in a project.
Testing should start early
Testing should start early during the Software Development Life Cycle
The testing team should be involved from the beginning of the project. This will help testers become more familiar with the requirements of the project. It will also help in capturing the forthcoming problems at a right time and with significantly lower cost. In advanced research, it’s been proved that with each advancement in the SDLC the average cost to repair the bug increases. Another benefit of starting test plans early in the Life Cycle is that the risk of getting a short time span for testing is greatly reduced. It would help to increase their test coverage and types of tests performed.

Test Case Sessions

Once the test team is involved during the early stages of the project, it will have sufficient time to prepare test cases and increase the test coverage. After preparing the test cases, a session should be arranged in which the test cases should be explained by the QA team with the concerned stakeholders including the developers. This session will help in finding out the ambiguities or discover any missing requirements. Test Cases should cover all the aspects of an application’s workflows without any assumption. Sharing the test cases with the developers and other stakeholders before the implementation phase will help developers to evaluate more chances of failure in their code

In-Depth Unit Testing

Before handing over the code by developers for testing, it’s best practice if they perform a thorough unit test of the code they have developed. This will help in finding the errors during the early stages of the development life cycle. It will also help in lowering the testing / retesting and the bug fixing costs of the project. Apart from that performing the unit testing will help in building code that can be reusable and easy to debug.

Some more Testing Practices

The testing team performs manual testing in salesforce and which includes testing like functional testing, integration testing, regression testing, and system testing. For the quality Salesforce implementation, there are some key practices that a tester must follow :

1. Before starting on with testing in a multi-environment setup, the tester should confirm with the development team that the changes and configurations have been deployed on the sandbox where the tester is starting to test in.
2. Before starting testing in salesforce it should be confirmed that the tester is using the correct logged-in profile as mentioned in the requirements and test cases. Never assume that system will work the same and as expected, whether you are using an admin profile or any other profile that has full rights.
3. To minimize any risks of the implications involved in the implementation of integration of Salesforce the testing team effort should be focused on the following areas:
   • The Source to target mappings for each category of data
   • 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.
   • The errors during the migration should be identified, investigated, and their disposition to be agreed upon.
   • It should be Validated that all-new workflow, assignment, approval rules, and email notifications are working correctly.
4. It should be validated that who access or 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), Page Layout Assignments, Record Types, Organization-Wide Defaults, and Field Level Security mechanism to be evolved.
5. If Manual sharing is there in requirements, testers should run tests to make sure that the records are correctly shared. Make sure that there is no impact to the overall Organization-Wide Defaults visibility of the records.
6. Some key areas that should be the focus of testing to validate Reports and Dashboards implementation are as follows:
   • Reports: Set of records that meet certain defined acceptance criteria, and is displayed in an organized way comprising rows and columns. It should be validated that the data has been properly filtered, grouped, and displayed graphically as a chart as per the requirements.
   • Report Type: Its the set of records and fields which are available to a report based on the relationships defined between the primary object and its related objects.
   • Dashboards: Administrators assign control and access rights to dashboards with certain visibility settings by storing them in folders. Each dashboard is having a running user and which data to display in a dashboard is defined by the security settings. Suppose the running user is a particular specific user, all dashboard viewers see data based on that defined security settings of that user—regardless of what the personal security settings of that user are. In the case of dynamic dashboards, the running user can be set to be a logged-in user, this way each user sees the dashboard according to their own access level.
   • Access to Reports and Dashboard Folders: Reports and Dashboards are stored in folders, depending on which control who has access. Folders can be categorized as public, hidden, or shared, and set to be 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 the assignment of the defects back and forth and quick turnaround. To ensure the defects are logged in the 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, the 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 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.