## Functional FAQs algoQA supports functional test design and automation across web, API, mobile, desktop, and business applications. These FAQs cover recording, locators, reusable automation, data handling, validation, test generation, and execution. algoQA converts application interactions, requirements, and prompts into functional test scenarios and executable automation. It can record user actions, identify application elements, generate test steps, and validate expected outcomes across supported application layers. algoQA scrapes the application's DOM to identify elements and their attributes during recording. The identified locators are stored with the generated automation so the test can interact with the corresponding elements during execution. algoQA supports functional automation for web, API, mobile, desktop, and enterprise applications. You can use it for positive, negative, boundary, end-to-end, regression, data-driven, integration, and validation scenarios. Yes. algoQA can fetch data from a source product, transfer or use that data in a target product, and validate the resulting values between both systems. Yes. A test can combine API and web actions in the same end-to-end flow. API responses can provide data for web actions, and web results can be validated against API data. algoQA can automate supported legacy desktop applications by interacting with their exposed controls and application interfaces. The exact level of automation depends on how the application exposes its controls. Preserve the trailing space in the parameter value rather than trimming the value before it reaches the test step. Use the parameter exactly as required by the application and verify the resulting value during execution. An alias step is a reusable name for an automation action or group of actions. Using an alias lets you refer to the underlying implementation without repeating the individual steps in every test. Add the missing action to the test after recording by inserting the required step at the appropriate position. You can then configure its locator, input data, and validation before executing the test. Tests can use conditions and loops to evaluate runtime values and choose the appropriate path. This allows a flow to branch, repeat actions, or stop based on data returned by the application. Common actions can be created as reusable modules and called from multiple test cases. Reusing a module avoids duplicating its implementation in each test, and custom scripts and libraries can be organized into folders for easier maintenance. Yes. Custom actions can accept parameters, allowing the same action to operate on different values, records, or application states without duplicating the action's logic. Additional Node modules and libraries can be integrated when the required dependency is supported by the execution environment. Code written in other languages can be used through an appropriate integration boundary or service exposed to the test. Yes. Test data can be kept separate from the automation logic and supplied at execution time. This supports data-driven testing and allows environment-specific values to be managed independently from the test scripts. Yes. algoQA can compare data displayed in a UI table with data from downloaded files such as XML or CSV. The comparison can validate the expected values, structure, and relationships between the two data sources. The objects identified during application interaction are managed as part of the algoQA project and its generated automation assets. The repository location depends on the project structure and the application type being automated. Yes. Existing generated scripts can be reused after application changes. Update the affected locators, steps, or test data instead of recreating unaffected automation from the beginning. Build coverage from the application's requirements, workflows, business rules, validations, and exception paths. Combine generated scenarios with positive, negative, boundary, integration, and end-to-end tests, then review the resulting coverage against the requirements. Yes. Test cases can be grouped, filtered, or selected by application module. This allows you to review and execute only the tests associated with a chosen set of modules. A test flow can be designed to handle exceptions and recover from expected interruptions. Whether execution resumes automatically depends on the configured recovery logic and the point at which the failure occurs. Different users can work with separate modules and test assets for the same application. Concurrent execution depends on the available execution environment and whether the application and test data support simultaneous use. Yes. Test data can include invalid, minimum, maximum, empty, and boundary values for data-entry fields. The test can then verify that the application accepts valid values and displays the expected validation for invalid values. Execution results can be reviewed by execution date and shared with the relevant users. Available download and sharing options depend on the report capabilities enabled for the project. Yes. You can select specific test cases for execution and arrange their priority according to the validation objective or business need. Yes. Test data can be entered manually for field-level validation or read from Excel for data-driven execution. The selected data can then be mapped to the corresponding test fields. Yes. Tests can validate UI content in different regional languages by using language-specific test data and expected values. The same functional flow can be executed against each supported translation. Gherkin scenarios can be generated from recorded actions, requirements, or prompts. You can review and adjust the generated scenarios when the business behavior requires additional detail. Test scripts execute through the configured algoQA execution environment. Migration to a separate infrastructure is not inherently required; the deployment and execution arrangement depends on the project setup. The generated test scripts belong to the project and can be reviewed and modified after generation. You can update the logic, data, locators, and validations as the application or test requirements change. Use domain-specific requirements, terminology, business rules, application context, and representative test data in the prompt or source material. Review the generated scenarios against the requirements before using them as executable tests. algoQA supports mobile automation for supported mobile application types and platforms. Mobile coverage is not limited to a single platform, but the exact capabilities depend on the application and configured mobile execution environment. Yes. algoQA can generate test cases for applications built with different technologies when the application exposes supported interfaces or user interactions. The generated flow is based on the application's observable behavior and supplied requirements. Yes. Data migration can be validated by comparing source and target records, field values, record counts, transformations, and expected business rules. The validation can combine API, UI, file, or database-accessible data as appropriate. algoQA can automate cloud-hosted applications through their accessible web, API, and supported application interfaces. The scope depends on network access, authentication, application behavior, and the execution environment. algoQA can work with existing automation assets and frameworks when their scripts, libraries, interfaces, or execution commands are compatible with the project environment. Integration details depend on the framework and the required level of reuse. MFA flows can be automated when the verification mechanism is accessible to the test and the required test credentials or verification codes are available. Additional handling may be needed for time-based codes, external devices, or out-of-band approvals. Test design includes defining the scenario, actions, data, and expected outcomes. The feature file expresses the behavior in a readable format, while the executable script implements those steps and connects them to the application actions and validations. Prompting can generate test cases from described requirements and application context. For an online application, recording is not the only option, but recording can provide additional application-specific details such as element information and interaction behavior. Auto-healing evaluates available element attributes and the surrounding UI structure to identify a suitable replacement locator. For dynamic, nested, or delayed elements, the test may also need the appropriate interaction sequence and synchronization. When multiple elements share an identifier, additional attributes, hierarchy, or index information is required to select the intended element. Expected data can be maintained with the test data or configuration used by the project. During execution, algoQA compares the observed UI or application result with the configured expected value, while environment-specific values can be separated through environment-level data or configuration. Supported automation flows can handle Windows alerts and pop-ups, file uploads and downloads, and file-content validation. Tests can also validate dynamic values obtained from files or accessible data sources when the required connector or integration is configured. Yes. Steps can be reused by placing common actions in reusable modules or custom actions and calling them from multiple test cases. Reuse keeps shared behavior consistent and reduces duplicate maintenance. Update the algoQA project when external changes affect the application behavior, locators, test data, or generated scripts. Bring the latest changes into the project by updating the affected assets and regenerating or synchronizing the relevant test content. Assign data by mapping test inputs to the parameters, fields, or steps that consume them. Data can come from inline values, external data files, environment configuration, or generated test data. Bulk data is mapped by associating rows or records with the parameters required by a test case or test set. The execution uses each mapped record to run the applicable test scenario with a different data combination. Yes. Requirements can be used as input to generate functional test cases and, where sufficient application context is available, executable test scripts. Review the generated output to confirm that all business rules and expected results are represented. Yes. Prompts can describe API workflows, request data, response expectations, validations, and dependencies between endpoints. The resulting scenarios can be reviewed and adapted to the API contract and environment. Yes. algoQA can be used to test LLM-based applications by validating prompts, responses, expected content, structured output, and behavior across representative inputs. Evaluation criteria should be defined according to the application's use case. Yes. Applications built on the .NET framework can be automated when their relevant interfaces and controls are supported by the configured algoQA automation capabilities. algoQA supports automation across web, mobile, API, desktop, and selected enterprise applications. Support for a specific product such as SAP, Pega, or BY depends on the product interface, application version, accessible controls, and configured automation capability. Yes. When a requirement or application change affects only part of the test suite, you can identify and regenerate the impacted test cases instead of regenerating the entire suite. Review dependencies before regeneration to preserve intentional customizations. Yes. algoQA can handle multiple application environments under a unified framework. It can automate Windows-based mobile applications such as POS, Android and iOS applications, and web portals such as e-commerce applications. Yes. algoQA supports combined multi-platform automation. You can create test scenarios that start in a web application and continue on mobile devices, enabling end-to-end omnichannel testing. Yes. algoQA supports Windows, Linux, and Mac; Chrome, Edge, Firefox, and Safari; Android and iOS handheld devices; and TVs.