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.

How To Use SFDX For Quality Assurance (QA)
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 your application's functionality. Apex 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.


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 team to troubleshoot and resolve the issues.
  • Data problems arise when data is incorrectly used in your application. Invalid data formats, incorrect data types, or missing data can cause these problems. You must 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 can 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 who can work on a feature can create a feature branch and a dedicated Hutte org. The developer will then want feedback, so they will submit it to Git. It can then undergo QA without interfering with the developer's concrete environment.

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.

Sebastian Lechner

Product Management Director of IPfolio

Source: Hutte

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 differently, 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

You can quickly return to earlier versions if you use Hutte – scratch org-based. 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.