Configuration Page
Last updated
Last updated
The UI configuration page for automation testing is utilized for managing:
Default Configuration
Add New Environment
Emulator Screen
Default screen
Integrate External Tools into our System
Cloud server setup
Cleanup Reports
Rename/Delete Test Component
Move Your Test Scripts
Add Your Locator For Web Element Identification
Set up tag For Automatic Web Element creation
Database Details
Global Xpath for Loader Content
The configuration page can be accessed by navigating to Automation > UI Testig > Configuration from the left navigation panel.
The default configuration section contains the following key:
The default environment can be selected from the default configuration section. This default environment will be displayed as the default selection on the Test Script, Execution Lab, and Custom Function pages.
The QA Bunch team has set a maximum value for the report trail count based on your account. However, you have the flexibility to choose a lower value if needed. The dashboard will then show you the execution history, time taken for execution in seconds, and the count of failed components, all based on your selected report trail count.
The "Days Save to Report" value is utilized for viewing detailed reports of test execution. For instance, if we set the value to 10, the "Detail Execution Report Last 10 Days" section will display data from the past 10 days. Users can select any date and time to view the corresponding reports.
Please note: The maximum value allocated by the QA Bunch team.
The "Days to See Development/Execution Count" value is employed for generating the bar chart on the dashboard page, allowing users to visualize the number of automation scripts created and executed on a daily basis. For example, if the development/execution count value is set to 10, users can analyze script development and execution for the past 10 days.
Please note: The maximum value allocated by the QA Bunch team.
By default, during automation execution, whether a test passes or fails, only one screenshot is captured. However, users have the flexibility to adjust this configuration. For instance, if we set the option to "Screenshot for Each Step," it means a screenshot will be taken for every test step. Nevertheless, we recommend sticking to the default values of "Failure & Success" because capturing a screenshot for each step could consume significant space and result in duplicate screenshots.
We have introduced a 'Timeout for Search Element' configuration option. The objective of this feature is to make the code internally wait for the specified timeout before interacting with any web elements. This acts as an explicit wait, eliminating the need for additional wait statements in the test scripts.
Video file for defualt configuration
The "Add New Environment" section is utilized for including a new environment along with its corresponding application URL. Typically, an application has various environments such as Dev, Preprod, and Prod, and this feature enables users to add and manage these environments. Once an environment is added, it becomes accessible on the Execution Lab page, Test Script page, Test Data page, and Custom Function page for convenient and comprehensive management.
The maximum environment count is determined by the QA Bunch team, and as per the current allocation, users can add up to 4 environments for each account.
After saving the environment, it can be accessed across multiple pages.
Video file for add new environment
The "Emulation" section is used for adding the emulator name provided by the Chrome browser, which is utilized for responsive testing.
If you inspect the Chrome browser, you can see a mobile icon that provides access to various emulators. These emulators simulate how your application will appear under different width and height configurations, allowing you to preview its appearance in various settings.
For this section, we can first select the device type, which can be either mobile or tablet. After that, we need to provide the screen dimensions that exactly match the Chrome mobile inspector window.
Once saved, the selected platform and device will be available on the Test Script, Custom Function, and Execution Lab pages. For example, if our chosen platform is Mobile and the device name is Pixel 7, the application will launch in Pixel 7 mode.
Video file for Emulator screen
The "Default Screen" section is used to set up the default platform. This section has the following key features:
Execution Platform
Browser
Mobile Emulator
Tablet Emulator
The "Execution Platform" is utilized for test script execution and offers three values: Desktop, Mobile, and Tablet. The primary purpose of this setting is to enable test execution on different platforms, with Mobile or Tablet indicating responsive testing. Once a platform is selected, the default value is available across all pages, including the Execution Lab page, Test Script page, and Custom Function page
The "Browser" field is used for selecting the default browser. The QA Bunch team allocates a list of browsers based on the selected account.
The "Mobile Emulator" is a list of mobile emulator names obtained from the Emulator screen. We can set the default mobile emulator screen for the Mobile platform.
The "Tablet Emulator" is a list of tablet emulator names obtained from the Emulator screen. We can set the default tablet emulator screen for the Tablet platform.
Video file for Default screen
This section is used for integrating QAautoMATER with Jira. After adding the Jira details, the defect management tool will be linked to Jira. This integration becomes handy in the event of automation script failure, as it allows for direct logging of defects into Jira.
Please Note : if this section is blank the Defect will be logged in QAautoMATER itself.
First of all, all Jira details should be filled. For example, the mandatory fields are:
Host: The hostname referring to the Jira base URL, excluding "https".
Username: The common user email used for defect logging.
Token: The user email token.
Project Key: The project ID.
On the UI Execution Lab page, a "Create New Defect" button will appear only for failed test cases. If Jira details are filled in on the Configuration page, the defect will be posted to Jira; otherwise, it will be logged into QAautoMATER itself.
While logging defects, the following protocol will be followed:
Issue Type will be Bug.
If the Current Test Cycle is not defined or does not match the project Sprint Name on the Manual Configuration page, the defect will be logged into the Project Backlog. If it matches, the Bug will be associated with the Sprint.
A comment will be added to the defect, mentioning that the defect was reported from the QAautoMATER UI window.
If any Jira references (such as Story or Task) are available in the Manual Test Case, the Bug will be automatically linked to those tasks.
If your account has multiple Jira projects, the project key can be passed using a comma separator on the configuration page.
If you want to pass the project name along with the project key to help users understand the project, you can include the project name with the project key using a separator. For example: ZYX-My X Project
If your Jira instance has custom issue types defined, you can specify your custom issue type name in the Custom Issue Type column. You can list multiple custom issue types using a comma separator. For example: Defect,. You can retrieve all available issue type names using the REST API call:
rest/api/3/issuetype
Video file for Jira Integration
The "Clean Up Reporting" section is utilized for deleting reports from the server. This becomes necessary after a certain number of executions, as the server may accumulate a significant amount of data. Deleting older reports that no longer add value helps free up space. In this section, reports can be deleted based on the selected environment. Additionally, a "Delete All" button is provided, allowing for the deletion of all reports for the chosen environment with a single click.
In this section, there are two fields: "Environment" to select the environment for reporting and another field named "Keep Report Data (timeline)," which is a listbox containing options such as 7, 14, 30, 45, and 60 days. For instance, if you select 60 days and click the Save button, the server will retain only the reports from the last 60 days. Any reports beyond this timeline will be deleted from the server.
Video file for Report Clenup
The "Rename and Delete Component" section is used for renaming a component or folder name and deleting the component or folder along with its associated automation test scripts.
Please note: Only administrators can view this section.
Any automation script is created under a component name or folder name. The automation scripts are actually saved in a folder referred to as the component name.
To rename a component, select the component from the listbox, provide the new name, and click on the Rename button. The component name will be updated, and all associated test scripts will be shifted to the new component name.
To delete a component, select the component and click on the Delete button. The component and its associated test scripts will be removed from the server.
Video file for Rename/Delete Component
This section is used for moving automation test scripts to a different component. For instance, suppose you initially have two test scripts for Component A, and later you realize that the test scripts should belong to Component B. With this section, you can move your test scripts from A to B.
To move test scripts, first, select the initial component from the listbox. After that, choose the test scripts that need to be moved from the 'Select Test to move' section, which is a multi-selection listbox. Then, select the new component from the 'Select Component to Move' section and save. After saving, the selected test scripts will be moved to the new component.
Video file for Move your test script
QAautoMATER allows you to add custom locator names for web element identification. Here, the locator name refers to the web element attribute name. A web element can be identified by various attributes such as id, name, class, link text, XPath, and CSS selector. However, this section enables you to add your custom locator, providing flexibility for element identification.
In these applications, development is done using various technologies like ReactJS, Vue, Angular, etc., where third-party libraries are utilized for components such as buttons and inputs. In some applications, traditional properties like id or name may not be present. Instead, you may encounter attributes like data-id, ng-click, or others in the HTML DOM. With QAautoMATER, you have the capability to add data-id, ng-id, etc., as custom locators to identify web elements in such scenarios.
You can add a custom locator based on your application's behavior in this section. Once added, save it.
Once it is saved, the custom locator can be viewed in the Test Script and Custom Function sections under the web element.
Video file for adding custom locator
QAautoMATER automatically generates web elements along with XPath. For generating the XPath, it takes the tag name from the configuration page. On the configuration page, we can define the parent tab for different types of web elements.
By default, QAautoMATER generates the parent tag for all web element types. However, if the application has different supported tags for specific web element types, you can update the tag for the respective web element type from the 'SET UP TAG FOR AUTOMATIC WEB ELEMENT CREATION' section.
Video file for update parent tag of the webelemet
From the database details section, you can add database details based on the environment. These database details are used for running queries on a specific environment.
Currently, QAautoMATER is integrated with SQL Server only.
Test execution occurs based on the environment, so if you want to run a query, QAautoMATER will pick the database details for that specific environment.
Video file for Database details
In the application, we internally utilize a page loader content to manage waiting. Within this section, we can specify XPath for the loader or skeleton content. The XPath defined for the loader will automatically verify its existence after certain actions. QA automaters will then wait until it disappears. At the test script level, we must include an additional step to handle this.
