## Technical FAQs Find answers to technical questions about algoQA frameworks, scripting, test design, execution, reporting, AI, and auto-healing capabilities. algoQA has features called ReScraper and Locator Mapping to identify delta changes whenever an application undergoes changes. The Auto-Healing feature helps to fix the DOM changes. Auto-healing handles locator changes for small updates. Larger feature changes require scenario or step adjustments. algoQA accepts requirement documents, existing test case documents, and defect information to generate test cases that help identify coverage gaps. algoQA has impact-based testing capability to detect code coverage gaps. Additionally, algoQA-generated test cases can be mapped to requirements using tags to provide coverage insights. Prompting works in offline as well as online mode. The algoQA model needs to be created with proper features and nodes to use Prompting. algoQA leverages LLM models to find the correct locators to heal the scripts. algoQA stores the locator information along with the parent DOM information, and algoQA identifies the unique locators using this data. The auto-healing feature in algoQA, when a locator fails, automatically attempts to find a new locator for the failed element based on its properties such as text, class name, or tag name. This new locator is then used to continue the test execution. The process of finding a new locator is performed dynamically during test execution. To enable the auto-healing feature, follow these steps: 1. After generating the script, download it to your local folder. 2. Open the folder where you downloaded the script. 3. Locate the ApplicationSettings.XML file and open it. 4. Set the auto-healing setting to True. 5. Save the changes you have made to the application settings file. The following features of algoQA leverage AI: Scraper, Auto-Healing, Copilot, Codebot for creating custom methods, Jira Defects to Test case conversion (Test design), Prompting, Auto test case generation, deduplication, Feature file quality analyzer, and Smart Ordering. AWS Bedrock for LLM Deployment. Amazon Bedrock foundation models. Prompting leverages the LLM for test case generation, and the offline model is the input for Prompting. Proper input data is required for the LLM model, otherwise you have to edit the test cases based on requirements. Handling unstable or highly dynamic DOMs in applications can be challenging during test automation. One approach to address this issue is to use dynamic locators and WebDriverWait with expected conditions. Dynamic Locators: Instead of using static XPaths or CSS selectors, use dynamic locators that can identify elements based on their properties or text content. WebDriverWait with Expected Conditions: Use WebDriverWait with expected conditions to wait for elements to appear or disappear based on specific conditions. algoScraper has the capability to get the optimal XPath for dynamic elements. Yes, algoQA's auto-healing feature allows the platform to adapt automation tests to match changes made to the application. Yes, algoQA's auto-healing feature can help adapt to application changes and update object IDs or locators as needed. This ensures that scripts remain functional even when the application's UI elements change. For more information, refer to Auto Healing. Auto-healing in algoQA addresses minor UI locator changes automatically while maintaining traceability logs. Major application changes still require manual validation. If the button attribute changed to btn, then algoQA will be able to heal. Generated scenarios are designed to be semantically accurate and contextually relevant, not guaranteed to be perfect or immediately executable. Accuracy should be understood as how well the scenario captures the intended business flow and reduces manual effort, rather than whether every step is correct without review. Not in the traditional machine learning sense. The foundation model used in the algoQA platform does not learn or update itself based on iterations or feedback. Improvements across iterations come from better input, clearer intent, and more relevant context, not from the model becoming smarter. Iteration refers to refining alignment, similar to how a human tester produces better results when requirements are clarified. Each iteration helps the system by: Adding missing context, Clarifying assumptions, Narrowing scope. It does not change the underlying model. RAG allows the system to ground generation in relevant UI metadata and existing scenarios at the time of test creation. This improves relevance and consistency, but it does not introduce learning or memory into the model. GenAI models are probabilistic, not deterministic. This variability helps explore alternative flows and edge cases but means output should always be reviewed. This behavior is expected and by design. No, GenAI is intended to accelerate and assist test design, not replace human judgment. Final validation, domain reasoning, and intent confirmation remain the responsibility of the tester. Yes, LLMs are used to provide stable locators and assist with online recording of test scenarios using algoScraper. However, this can be bypassed with a minor performance degradation. AI is not mandatory to record automation scripts in algoQA. algoQA offers multiple approaches to test design. Test cases can be created using offline recording which is not AI dependent. AI-assisted test design using text inputs like natural language test intent prompts, defect descriptions, and manual test cases accelerates automation resulting in a significant productivity boost. AI features in the algoQA Platform: algoQA-CoPilot uses AI for real-time in-product assistance. Test Design leverages AI to generate test cases. Code Generation uses LLMs to assist with extending default frameworks. Optimization and Deduplication assesses feature file quality and detects duplications. Auto-Healing of Scripts detects locator/label changes during execution and automatically fixes failed script runs. AI cannot be disabled in SaaS deployment. For on-premises deployment, GenAI features are disabled by default unless specific conditions are met: 1. algoQA Bedrock Domain Whitelisting: Customer firewall or VPC must allow outbound HTTPS access. 2. Provide Matching AWS Infra: A dedicated Bedrock-enabled AWS account/environment must be configured. 3. Customer-Hosted Equivalent Models (Unsupported). Key Considerations: algoQA does not commit to deploying or managing LLMs on customer infrastructure. If GenAI access is unavailable, features degrade gracefully. Customer test data never leaves their infrastructure if using on-premises with Bedrock access. AI is not required for offline recording. For online recording using algoScraper, LLMs are used to provide stable locators and assist with online recording. However, this can be bypassed with a minor performance degradation. If UI changes slightly, you do not need to re-record all scripts. algoQA employs auto-healing mechanisms to handle minor UI changes. When a script fails, the agentic AI in algoQA updates the locator and re-executes the script. These updates are reflected in both the script and the object repository. Yes, you can use algoQA purely as an automation tool first and add AI later. Yes, automation can be done completely without AI. While AI can accelerate automation and reduce manual maintenance through features like auto-healing, it is not mandatory for performing automation with algoQA. Test data is generated based on the scenario automated. Test design and Script execution. Auto-healing can be turned on or off, either globally or locally. When it does heal, it is useful for superficial changes like locator or label changes. It will not auto-heal a broken workflow chain, since that kind of change is more likely to reflect a design change or an actual defect rather than a cosmetic one. Yes, When auto-healing proposes a UI-related change, the end user can review it and decide whether it is appropriate, then approve or decline it. Only after approval are the scripts actually updated. It functions similarly to a static code analyzer, but for feature files. It flags missing assertions and recommends where they should be added, checks for good documentation practices, and suggests improvements when a step does not have a meaningful name. The same scenario executed across multiple datasets is treated as a single scenario rather than counted as duplicates. The engine highlights scenarios that are 95-100% similar as well as those in the 90-95% range, so teams can identify and consolidate near-duplicate test cases. The underlying model for deduplication is not trainable. However, the user can customize the level of similarity for determining duplicates both at feature file and test script levels. Impact-based testing focuses on identifying and executing test cases most likely to be affected by a change. algoQA uses: 1. Test Impact Analysis to determine affected test cases. 2. Test Prioritization based on impact and importance. 3. Test Automation to generate test cases for the changed feature. 4. Test Execution to verify functionality after the change. Yes, if an element is healed during execution, the update is reflected in the object repository and can be pushed back to version control (e.g., Git). If you prefer not to record test steps using algoQA, you can use the prompting feature where you can generate test steps in Gherkin language. algoQA generates test cases that can be reused across test scripts. Yes, algoQA's auto-healing feature automatically detects and fixes locator changes during script execution. When a locator fails, the platform uses stored element properties and parent DOM information to find the correct replacement locator, then continues execution. Healed locators are also updated in the object repository. For a Qt-based embedded device, the test suite can use the IP address and port number to detect the external device and execute the scripts. Yes. You can execute tests in virtual mobile environments. Appium scripts generated by algoQA can run on Android Studio emulators, simulators, and similar virtual mobile environments. Maintenance is the biggest barrier to scaling test automation — teams eventually spend more effort repairing existing automation than increasing coverage. Self-healing addresses superficial changes like locator updates but cannot handle real workflow changes such as adding OTP steps, replacing UI elements, or modifying business flows. A self-maintaining test estate needs bulk and prompt-based updates that identify affected tests, reuse existing assets, and keep cases current without manually editing thousands of scripts.