Types of Salesforce Testing
Manual software testing process includes the testing of Salesforce.com App by using traditional methods. QA team can use manual testing can be used to execute UI testing, functional testing, integration testing, regression testing, User Acceptance testing, production testing and system testing.
Automated testing involves a computer program to test a Salesforce.com or Force.com app. Automated testing tools like Selenium, Assure Click, QTP, etc. are used.
Levels of Testing in Salesforce
- UI testing
- Functional testing
- Regression testing
- System testing
- Integration testing
- User Acceptance testing
- Production testing
A tester needs to be cautious during UI testing as most of the web pages on Salesforce platform are Visual Force pages. The dynamic nature of visual force pages need to be paid special attention as all the elements of a webpage may not be loaded at one go
Example: On the below Contract object we need to verify the below things
- All the fields are properly displaying as per the User story# or requirements.
- User is able to select picklist values, Lookup fields properly on the page.
- Check for required fields and non-required fields validation messages if any while saving the record.
- Check all the sections are displaying properly along with alignment.
- Check all the related lists are displaying with all the data
- Check the page layout displayed as per the requirement
2. Functional Testing:
Testers need to create functional flows including positive and negative flows to cover the entire functionality of an application as per the requirements or user stories.
For example-1:Using workflow when the field status is updated to Application uploaded on the Contract object Task should be created on the related list.
Screen-1 – Status is Application Uploaded.
Screen-2 Task is created.
Example-2 – When particular Contract created it will assign to default user group using assignment rules.
Screen-1 – PL Contract is created with PL Contract Record Owner is
Regression testing in sales force to make sure testers need to test existing functionality or components are working fine when new components (classes,Visual force pages, workflows,triggers,Process builders,Integration procedures etc..) or defects fixes deployed in the Org.
Consider a product packet of documents, in which one of the functionality is to trigger confirmation, acceptance, and dispatched emails when Confirm, Accept and Dispatch buttons are clicked.
Some issue occurs in the confirmation email and in order to fix the same, some code changes are done. In this case, not only the Confirmation emails need to be tested but Acceptance and Dispatched emails also needs to be tested to ensure that the change in the code has not affected them.
Integration testing is combining individual modules to verify functionality.
This type of testing builds a “working” version of the application by incrementally putting modules together. The objective is to ensure that as sales force , other modules(ETL, Vlocity, Mule soft,any other third party application etc..) are added, functionality remains intact. It is necessary to prove that the sales force and its integrated modules can work in unity.
The project featured a B2C e-store for a large multi-industry company running chains of gas stations along with roadside diners, gardening centers, as well as retail and wholesale stores. The customer already had a B2B e-store and an ERP system with affiliated BI and accounting modules. The new e-store had to be integrated with these systems.
As the project proceeded, the customer asked the development team to add new functionality to the ERP system. These were invoices to be sent to the customer’s buyers and suppliers. Meanwhile, the existing B2B e-store had to remain fully functional. To allow for this, the project team reproduced a copy of the production database and worked in an emulated test environment.
To implement integration testing efficiently, the testing team mapped the project structure:
Relying on the project structure, our testing team developed the integration testing strategy that covered two integration types:
Invoice functional unit + ERP system (component integration testing). New B2C e-store + ERP system (system integration testing). In our case, ERP system was updated with new diverse items every other day. Pricing policy (discounts, sales, loyalty programs, etc.) also changed oftentimes. So, the team opted for manual integration testing.
Component integration testing example: Invoice unit + ERP system:
For example, the new module didn’t process discounts. If a product was on sale, the customer received the invoice featuring the regular price. Another critical defect concerned VAT. Invoices contained amounts of VAT different from those in the waybill. This could hurt the customer’s reputation badly.
System testing is testing the entire system as per the project requirements. This covers all combined parts of the new application along with integration to existing objects in your Sales force org.
Example: New B2C e-store + ERP system
This type of testing had to verify that the ERP and the new e-shop were seamlessly connected and responded to mutual queries. Most important integration points included:
- Same prices in the ERP and the shop.
- Correct goods on sale.
- Correct information processing in the ERP system if a good is sold/returned.
The success of integration testing for these modules was critical. If something went wrong, the e-store customer UX would be hampered.
Testing uncovered various integration issues with the severity ranging from medium to critical. The most important bug was the e-store crashing when an e-shopper added an item to the cart. Another critical bug covered the e-store’s inability to process the amount due for several items when the user pressed Enter button.
As for bugs of medium severity, the most significant one considered the rounding of the amount due. While for users this bug was insignificant or even pleasant (in case of rounding towards a lower cost), it wreaked havoc in the customer’s accounting module. Verifying that the accounting documents and the ERP data added up involved considerable efforts of the manual testing team.
6. User Acceptance Testing:
User Acceptance Testing is the final stage of testing before the system is accepted by the operational user. End users perform UAT based on the user requirements specifications to confirm whether sales force application is meeting requirements or not.
Sales force testing will perform in production sandbox (real time environment).