Quality Assurance (QA) has long been the “Jon Snow” (neglected stepchild) in Salesforce Project Delivery with flashier phases like Solution Design, Build or Discovery stealing the limelight. But when done properly, QA, much like the Game of Thrones character, can play a critical role in saving Westeros (your deployment) from complete and utter devastation.
Failing to properly define and plan for QA testing in any Salesforce project will inevitably lead to issues caught during User Acceptance Testing (UAT), potential post-deployment bugs, rework, and Salesforce user and administrator dissatisfaction.
To complete the analogy, QA serves as the “Night’s Watch” of Salesforce project delivery, lighting the signal fire to raise alerts of any defects, unexpected behavior and minimizing the oncoming Wildling horde of Salesforce admin and user questions. That’s the last of the GoT references, I promise.
10 Dos and Don'ts of Salesforce Quality Assurance Testing
Here are 10 Dos and Don’ts of Salesforce QA Testing:
1. Do: Plan for Issues that Will Arise During QA Testing.
Not to contradict the much-cited Benjamin Franklin quote, “Failing to plan is planning to fail,” but I would argue that with QA, it is necessary to plan to fail.
In other words, QA testers worth their salt will nearly always discover issues, or at the very least, raise questions about unexpected results upon running end-to-end testing. In fact, when zero feedback arises during QA, it is a telltale sign that the tester may not have done enough testing.
Such is the case when project teams are on a time crunch to mark the QA phase as “complete.” By allocating time in anticipation of bugs and issues, a project team sets itself up for a smooth delivery plan.
2. Don't: Ask the Salesforce Solution Builder to Test.
As my tech lead often reminds me, to assign testing to the same party who built a solution is like asking the fox to guard the hen house! Or like Amazon proposing regulatory guidelines on AI... but I digress. The same principle also applies for asking the Salesforce solution builder how to test a specific feature.
Instead of getting test steps from the person who built the solution, one ought to refer back to the requirements to decide how each part of the solution should be tested.
3. Do: Map Salesforce User Stories to Test Cases
During Discovery, documenting Salesforce user stories should come as second-nature for any project manager (PM) trained in the Agile framework. While it may seem like an unnecessary step, listing the individual user stories on the testing document and mapping the coverage by test cases is worthwhile to ensure requirements are accounted for when QA is reached.
While drawing a diagram may or may not be helpful, beginning this process early on will translate to time saved during QA. During the progression of the project, mappings and test cases will need to be updated as initial requirements evolve.
4. Don’t: Get Smoked During Smoke Testing
Piggybacking off of #2, the only testing a developer or builder should be conducting is light smoke testing (A.K.A. Build Verification Testing) to confirm basic functionality as they complete code blocks or components.
Smoke testing cannot serve as a substitute for full end-to-end testing that is performed during the QA phase. It is merely a non-exhaustive way to confirm most important functions work. Don’t get lost in the smoke!
5. Do: Document. Organize. Repeat.
I cannot emphasize enough the importance of writing detailed test documentation in an organized structure. A well-written test document will not need explanation but will clearly communicate to the reader how to replicate any given test case. It should both be detailed and straightforward enough for any member involved in the project to reference.
Best practices include:
Using a naming convention where each test case is unique and easily identifiable - I prefer borrowing from the semantic versioning format (1.0.1 - major feature.minor feature.user)
Writing test steps with a non-technical end user in mind, limiting assumptions of the end user’s know-how
Erring on the side of granularity with test steps (e.g. Navigate to the dropdown menu and select the button labelled “Home”)
Starting test documentation early on and maintain it throughout the progression of the project rather than waiting for QA to write all your tests from scratch
6. Don’t: Stick to One Type of Testing
While it may be tempting to run through end-to-end functional testing and wash your hands of QA, it’s important to conduct multiple types of testing in order to cover multiple scenarios and simulate real-world product usage.
From integration testing to usability testing to browser compatibility testing to accessibility testing, there is no end to the types of testing. Define testing methods based on the scope and requirements of the project.
For an introduction to Regression Testing in Salesforce: https://salesforceben.com/introduction-to-regression-testing-in-salesforce/
For a comprehensive list of testing types: https://www.softwaretestinghelp.com/types-of-software-testing/
7. Do: Prepare Sufficient Test Data
Since a majority of cases will have QA testing performed in sandbox environments, having an appropriate volume and variety of test data is key for the QA phase to prove valuable. When possible, conduct testing with a full copy of production data.
Performance testing will only work as well as the test data matches the data in the live environment. Be sure to assign the task of importing test data in the early stages of the project to give the party responsible ample notice before the project reaches QA. The last thing you want is a delay in the project because the test data is not ready.
8. Don’t: Rely 100% on the Robots
While the advent of automated testing has brought increased speed and reliability, it has not replaced the need for manual testing. Many aspects of QA testing are still best performed by a human QA tester as programmed scripts are still limited in usability testing, exploratory testing and other qualitative measures.
If automated testing is incorporated into the project, be sure to utilize its native strengths for performance testing and regression testing. A combination of automated and manual testing will often minimize the chance of bugs reaching UAT. Not every Salesforce project requires automated testing, but I dare say that every Salesforce project will need some amount of manual testing.
9. Do: Negative Testing
It’s easy to move on after expected outcomes are achieved, but don’t forget to conduct negative testing for every positive test case. By inputting invalid data, deleting default values, exceeding the character limit, using special characters, and other methods of searching for flaws, a QA tester ensures that the product will be ready for rigors of a real-world environment.
10. Don’t: Rush the Process
The best gift anyone can give a QA tester is more time!
In this age of rapid releases and accelerated software development, all too often is QA testing overlooked, assigned minimal hours, or simply seen as a checkbox to be marked. Cutting QA short to meet the deadline may be tempting, but it is not worth the cost in the long run. In fact, teams should look out for how QA testing is discussed from the start. If it is lumped together with User Validation, seldom mentioned or treated like an afterthought, that indicates an expectation for QA to be limited or unnoteworthy. If that’s the case, refer back to #1!
Remember that QA is the last line of defense before teams can get their hands on the product, and it can be the difference maker between a successful deployment and one that causes issues down the road.
Finally, trust the QA process and take pride in the quality you’re adding to the product!
Contact CRM Science Salesforce Consultants
The CRM Science Salesforce consulting team understands the importance of quality assurance testing in every Salesforce project, and they have the experience to complete exhaustive testing initiatives. Contact us to chat about your Salesforce projects.
Jon Chen Salesforce Analyst CRM Science
