How To Use SFDX For Quality Assurance (QA)
QA (quality assurance) in SFDX involves testing the functionality of your Salesforce application and ensuring that it meets the expected quality standards.
Table of contents
Here are some steps you can follow to perform QA in SFDX:
Create a sandbox
SFDX allows you to create a separate environment to test your application without affecting the live version. Create a sandbox to test your changes before deploying them to the live application.
Write test classes
Write test classes that cover the functionality of your application. You can use Apex to write your test classes, which is a programming language used in Salesforce.
Run tests
SFDX allows you to run your test classes in the sandbox environment to ensure the application works as expected. You can run tests from the command line or the SFDX extension in Visual Studio Code.
Debugging
If you encounter any issues while running tests, you can use the debugging tools provided by SFDX to troubleshoot the problem.
Deploy changes
After successfully testing your changes, you can deploy them to the live application using SFDX.
Continuous integration and continuous deployment (CI/CD)
You can automate the QA process by setting up CI/CD pipelines. This will help you ensure the application is constantly tested before any changes are deployed to the live environment.
QA In The Development Lifecycle Can Present Challenges
QA may be conducted very early on in the development lifecycle. If you QA too early, you may encounter errors, including the following:
- Test failures occur when your test classes fail to pass. Various issues, such as code errors, missing dependencies, or incorrect test data, can cause this. When you run tests using SFDX, it will provide you with detailed error messages to help you identify and troubleshoot the issues.
- Deployment errors occur when you try to deploy changes to the live application, but they fail to deploy successfully. Various issues, such as invalid metadata, insufficient permissions, or validation rules, can invoke this.
- Integration issues occur when your application integrates with external systems, and there are issues with the integration. Various factors, such as invalid credentials, network issues, or incompatible API versions, can trigger this. When encountering integration errors, you must work with the external system's team to troubleshoot and resolve the issues.
- Data problems arise when there are issues with the data being used in your application. Invalid data formats, incorrect data types, or missing data can cause this. You will need to ensure that the data used in your application is correct and consistent across all environments.
- Performance issues take place when your application is not performing as expected. Inefficient code, long-running queries, or excessive API calls can create these problems. You will need to monitor the performance of your application and optimize it as necessary to ensure that it meets the expected performance standards.
QA ‘Left’ And ‘Right’ With Hutte
↔️
Overall, with QA, you can either follow the ‘left’ or ‘right’ approach. When shifting left, you do QA as early as possible. On the other hand, shifting right is leaving QA right until the end.
It is advisable to QA early on before you integrate and shift. With Hutte – a web-based interface that visually simplifies version control for Salesforce – this process is more accessible by:
- A developer being able to share the environment by sending the issue tracking system as an example. You can then open the Hutte org and QA it via a one-click login. The org’s work can be assessed and collaborated on. You can also create an org from the working branch
- A developer having the ability to work on a feature, create a feature branch, and a dedicated Hutte org. The developer will then want feedback. They will submit it to Git. It can then undergo QA without interfering with the concrete environment of the developer.
You can go to Hutte and create a new scratch org. Instead of doing it from the main branch, you can select a feature branch or create a fresh org.
Hutte is truly one of the best tools that we use. Product owners, Salesforce solution architects, business analysts — anyone on our team can easily and visually accomplish the tasks that would otherwise take a lot of clicks, time, and coding.
There will be no risk being out of sync or the developer having an additional configuration on Git.
Automate Your Integration
You can play around with data in different ways, provide feedback, and throw away the org.
You don't have to worry about complex command line interfaces (CLI). You can utilize a simple visual interface and have streamlined collaboration.
As a QA manager, you can directly view changes in a line-by-line comparison format from Git hosting providers.
🕑
Hutte automates the generation and integration of all required data, saving you valuable time that would otherwise be spent manually replicating scratch org data.
Return To Earlier Versions
If you use Hutte – which is scratch org based – you can quickly return to earlier versions. In Salesforce trial orgs and sandboxes, you can’t roll back.
With Hutte, you pick a branch (such as a release branch) and look at how QA worked in previous versions. Without Hutte, it is nearly impossible to do.
To see how Hutte works, start your free 30-day trial, or you can check out our interactive demo below:
QA As Early As Possible
With Hutte, it’s about getting to a specific state by conducting QA on a future branch that is not yet integrated or on a past branch to see how behavior has evolved over time.
🤯
Essentially, any QA manager can conduct their tests using Hutte, all in a no-code way.
Authors
