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:
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 AuthorFollow on Linkedin More Content by Neerav Patel