On-Demand Testing with Testing as a Service in Global and Country-Specific Salesforce Releases

October 28, 2019 Neerav Patel

Businesses of all sizes and in all industries -- finance, communications, retail, healthcare, manufacturing, technology -- in the APAC, ANZ, EMEA regions operate Salesforce. They use Salesforce to conduct the following: 

  • A global implementation of all the modules with standard functionality (centrally implemented). 
  • A country-specific rollout in each release: an India release, a China release, etc., with localized requirements incorporated (locally implemented). 

As an example, consider an electronics business dealing in laptops, desktops, and other external peripherals across countries. This business has four modules:  

  • Account module comprising all the accounts 
  • Opportunity module comprising all the related opportunities 
  • Product module comprising all the products 
  • Quote Module generating quotes against opportunities and product 

If this vendor has an opportunity to sell 1,000 laptops to an Indian university, the quote for this opportunity might need to have CGST/SGST taxing, VAT, etc. However, if the vendor creates an opportunity to sell laptops to a Chinese university, the respective quote will include China’s taxation system, and likewise in other countries. The products would remain the same across all countries.  

Testing as a Service: In theory 

In this use case, a one-time global implementation for the four modules -- account, opportunity, product, and quote -- is straightforward. The challenge lies in ensuring the integrity of the functionality when you perform a local implementation (per country) for the quote module. For instance, the following requirements must be considered: 

  • Local governance rules, local laws, local taxes, etc. 
  • Legal requirements for each country 
  • Local language, currency, and time zones 
  • Local culture 

Additionally, the implementation team must ensure that incorporating the local requirements in specific modules does not impact other modules. As such, the implementation team will create testing solutions that are 

  • Scalable, on-demand, and cost-effective for every country’s release. Doing manual end-to-end testing for every release is not a feasible option from a budgeting perspective.  
  • Robust enough to ensure fractional testing across modules whenever there’s a requirement change in any module (global or local). 

This generates the need to strategize Testing as a Service (TaaS), an on-demand testing capability that offers faster provisioning of services with lower costs. TaaS can be offered either through a cloud-based environment or through the current on-premise environment. 

Testing as a Service: In practice 

To illustrate the benefits of TaaS, consider again the electronics vendor selling computers across the globe. 

The global implementation of all four modules by using the following strategy provides a promising one-time solution:    

Implementing Strategy Chart - Testing-as-a-Service (TaaS)

We will have the following set of test deliverables ready for all modules. This will be a one-time investment: 

Functional test cases for each module created and executed 

Automated regression test cases for each module created, automated, and executed 

Automated end-to-end test scripts that cover all modules created, automated, and executed 

Mobile test cases are created, automated, and executed 

Migration testing scripts for master data created and executed 

Integration testing scripts created and executed 

Now, when the organization plans its India release, the quote module has to be tweaked with the India-specific local requirements, but the remaining modules are the same. That means for the India release, only the following activities will happen: 

Update functional test cases for the quote module. 

Update automated regression test cases for quote module. 

Update end-to-end test cases, incorporating changes for the quote module only. 

Create a new migration test script for transaction data. 

Update integration test scripts for the quote module only. 

Again, if the organization plans a China release, the activities in points A through E will not be performed for all modules but only for the quote module. 

For the India and China implementations, there’s less effort required because the existing test scripts will be leveraged. Ultimately, you enjoy the following benefits of Testing as a Service:   

A standardized testing process with predictable and reliable outcomes 

On-demand testing capacity 

Reuse and recycle 

Flexibility in tools, assets, and framework of choice 

This hypothetical use case is used to explain TaaS in the most comprehensive way, but we have successfully started to use our testing methodology as Testing as a Service in recent client engagements. If you’d like to learn more, reach out to an Appirio consultant today. 

About the Author

Neerav Patel

Neerav Patel is a Manager in the SFDC QA practice. His primary roles and responsibilities are to identify the challenges we face in QA delivery, plan the appropriate course corrections, and refine our existing processes. To deliver quality and respond to challenges without delay, he ensures the team always strives for continuous improvements. Neerav also leads the Data Migration and Integration QA practices, and he currently holds the QA Governance lead role on the top medical device company account.

Follow on Linkedin More Content by Neerav Patel

No Previous Articles

Next Article
Simplify Sending Email to Non-Contacts with renderStoredEmail Template
Simplify Sending Email to Non-Contacts with renderStoredEmail Template