How to use SFDX for quality assurance (QA)

Here are some steps you can follow to perform QA in SFDX:

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

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

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.

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.