QA and UAT is for Testing Processes Too (Not Just Code)

by David Masri

When I look at how Salesforce integration/migration specialists tend to go about migrating data to Salesforce code, I often see a process that looks something like this:

1. Data is delivered. 
2. The dev does some data analysis and authors some sort of data mapping document
3. The dev transforms the data for the first object (at the top of the hierarchy) 
4. The dev loads that object to Salesforce
5. The dev fixes errored rows for that object 
6. Rinse and repeat for the rest of the object to be loaded
7. Once all Objects are loaded, they email the client and tell them to “Test Away!”
8. The client does some testing & logs some defects
9. The dev fixes the data for the defects as they come in, and then asks the client to “retest it”
10. After a few weeks, no more defects are found, and the client signs off on the migration. They then ask the dev to “wipe out all the data and reload it with current data”
11. The dev wipes out the data, reloads it, and asks the client to retest
12. The client retests and is now fuming as the data looks nothing like what he just signed off on. Not only that, but many of the same defects previously reported are back!

What went wrong? Our dev made the biggest mistake you can make when migrating data to Salesforce. That is - to think of data migration code as one time run code. As they are fixing the data for the defects found, they only fixed the data and not the process or code! But there is another major problem here, and that is that only the data was tested and not the process, so when the migration was redone, the data came out differently, as people are just not good at performing long detailed tasks repeatedly in a consistent fashion.  

It’s imperative that you test your deployment and migration procedures as well as the code and resulting data. To do this, for each round of QA and UAT, perform all tasks as they will be performed during the production deployment. With each round, update your deployment procedures with any changes needed and add automation when possible, removing manual steps. By your final round of UAT, deployment should be flawless, with no changes needed.

For each round of QA and UAT, reset your target Salesforce org back to its originating state—that is, the state it will be in at the time of go-live. For migrations, this is the only way you can perform any testing properly. For integrations, this practice allows you not only to test your integration code, but also to test your deployment procedures.

For integrations, by the time you get to UAT, the integration processes should run as they would in production. This means that realistic data is delivered as often as it would be during production, with the same consuming and processing that would happen during production.

_{This article is adapted from my book Developing Data Migrations and Integrations with Salesforce: Patterns and Best Practices (Apress December 2018)}

About the Author

David Masri is Technical Director with Capgemini Invent, a Salesforce Global strategic partner, and is Data Strategy and Architecture Lead for their Salesforce Practice. He has over 20 years of hands-on experience building integrated ERP, BI, e-commerce, and CRM systems, with the last five years working exclusively with the Salesforce platform. He holds over 10 professional certifications, including 7 Salesforce certifications, the PMP, and Google’s Data Engineer certification. David has been involved in dozens of Salesforce migration and integration projects and has used that experience to run numerous training programs for aspiring Integration/Migration specialists.

This article was contributed by David Masri, author of Developing Data Migration and Integrations with Salesforce.