Automation Quality Assurance (AQA) in the Salesforce development practice
Automation Quality Assurance (AQA) is a testing process that focuses on ensuring that a product or service meets the required standards and specifications. AQA is crucial in delivering high-quality products by testing and verifying the product's functionality, performance, security, and compatibility with different systems and devices. It’s a generally applicable process in web development, including the Salesforce environment.
Automation can significantly improve the quality and efficiency of the Salesforce development projects. It involves using specialized testing tools or software to run tests automatically, instead of manually, and many of them are compatible with Salesforce. It helps in reducing manual errors and saving time, allowing Quality Assurance (QA) teams to focus on more critical aspects of testing, speeding up the delivery process.
The benefits of AQA in Salesforce
- Increased efficiency and speed of tests running;
- Minimized manual errors and reduced testing time, leading to higher accuracy and reliability in the QA testing;
- Improved test coverage, which tests the application under different scenarios and conditions that are impossible to replicate manually;
- More extensive testing, which leads to better code quality and fewer bugs, thus increasing customer satisfaction;
- A higher return on investment due to the reduction of manual testing efforts.
The tool for Salesforce AQA
By leveraging dedicated automation tools, Salesforce developers can improve the accuracy and reliability of their QA testing. At Noltic, we use WebdriverIO, which is ranked as one of the best automation tools of 2023. WebdriverIO is the next-gen browser and mobile automation test framework for Node.js specifically. It is a popular automation testing tool that simplifies web application testing by providing a simple and concise interface to enhance user experience. Its features such as browser support, command API, and test runner make it a valuable asset in app development.
AQA application in real Salesforce projects
One of the most showcasing appliances of test automation was the Hire Genius app implementation. Since this application is designed for HR usage, it required a lot of manual user functionality. The application development process required a lot of testing time to provide better quality. To cover all possible user functionality, we used the WebdriverIO framework. We were able to execute our tests simultaneously for different types of users (e.g. Candidate as Contract user and Candidate as Permanent user), covering the whole flow for the recruitment process. We were also able to run our automation tests in different browsers.
The popular design pattern of automations test creation is the Page Object Model (POM), and it was utilized in the same Hire Genius project. Using POM is better for enhancing test maintenance and reducing code duplication. Since the structure of Salesforce pages is similar to POM, it was an obvious choice in this project.
For the Hire Genius project, we created a separate class for each page. All the functionalities of the page were encapsulated in their respective classes. This allows for code reusability and single-point maintenance. If there's a change in the page, we only need to update the corresponding page class, minimizing effort associated with updating test scripts on each test cycle.
We also created separate pages (classes), as shown on screenshot above (folder named "pages"). For example, the Home.page.js file consists of the classes which encapsulate the corresponding functionality placed on the Home page of the Hire Genius app. Each subfolder includes separate pages related to application functionality. If the custom elements (such as tabs, dashboards, pipelines etc.) are placed in corresponding pages, we create separate subfolders including the class with related classes (see screenshot below).
The same structure was used for modal screens creation.
Also, this approach was utilized for component structures creation. Since in Salesforce components structure is used in page creation, we used it in automation tests component creation.
All components were split to separate classes depending on the functionality provided. For example the “input” component consists of different types of input (UiInputText, UiInputSelect, UiInputSearch etc.) and related functionality was implemented in it.
This way of automation test creation is much more readable and structured, and promotes the separation of test code from page-specific code. This separation makes the test scripts cleaner and easier to understand and utilize.
