9.13 - Test Designer 2.0 / Test Designer 3.0 Test Designer 2.0 / Test Designer 3.0 — Knowledge Base articles. Legacy Test Designer 2.0 and 3.0 Reference Legacy Test Designer 2.0 and 3.0 Reference This page is legacy reference material for older Test Designer 2.0 and 3.0 assets. Current documentation should use Scenario Editor terminology and workflows. Recommended guidance Do not use this page as the starting point for new tests. Keep only migration-relevant guidance for older maintained assets. Replace “Test Designer” wording with “Scenario Editor” in current procedures. Flag obsolete content for consolidation when a current Scenario Editor article exists. Validation workflow Identify whether the asset is still maintained. Use current Scenario Editor guidance first. Retain legacy details only when needed for migration. Document the replacement article or migration outcome. Last updated: September 20, 2026 Automating Multi-Factor Authentication in Scenario Editor Automating Multi-Factor Authentication in Scenario Editor Automate MFA only in approved test environments where the authentication flow is designed for repeatable testing. Do not bypass MFA protections in production or capture real user secrets in scenarios. Recommended options Use a test-only account with an approved MFA method. Prefer test bypass codes, sandbox identity-provider rules, or dedicated automation policies when the customer provides them. Store any test tokens or secrets in secured variables, not directly in steps. Use Scenario Editor validations to confirm the post-login state instead of relying only on timing. Document the identity provider, test account type, and approved MFA handling pattern. Validation workflow Confirm that MFA automation is approved for the target environment. Run the login flow once manually and document the expected challenge. Add the Scenario Editor steps using test-safe inputs only. Validate the landing page or authenticated state after MFA completes. Review logs to confirm secrets are not printed. Security note: This article is for authorized test automation only. It must not be used to weaken or bypass MFA for real users. Last updated: October 8, 2026 Browser Versions for Scenario Editor Testing Recommended guidance Browser version alignment is important for reliable Scenario Editor playback. Validate the browser, browser driver, Test Node, operating system, and AIQ version together before treating a failure as a scenario defect. When to check browser versions A scenario fails after Chrome, Firefox, Edge, or the operating system updates. Playback works on one Test Node but fails on another. Selectors, downloads, popups, certificates, or permissions behave differently between runs. Headless and headed execution produce different results. Recommended checks Record the browser name, browser version, Test Node, operating system, and AIQ build used for the run. Confirm the browser is supported by the current AIQ release and the selected execution mode. Check enterprise-managed browser policies before changing browser settings. Reproduce with a controlled browser version when troubleshooting regressions. Update documentation and execution notes when a browser version becomes a known dependency. Terminology note: Use Scenario Editor for current AIQ authoring and playback references. Older Test Designer references should be treated as legacy unless the page is specifically describing a legacy asset. Last updated: October 5, 2026 Automate Scrolling in Scenario Editor Automate Scrolling in Scenario Editor Use scrolling when the target element or content is not currently visible in the browser viewport. Prefer scrolling to a stable element or section over relying on pixel-only movements. Recommended workflow Identify the element or section the scenario needs to reach. Scroll until the target is visible and stable. Use a conditional wait if content loads asynchronously after scrolling. Perform the validation or action once the target is ready. Good practices Avoid scroll steps that depend on a specific screen size unless that is the test objective. Validate the target element after scrolling before clicking or typing. Document mobile or responsive behavior separately when scrolling differs by viewport. Last updated: September 9, 2026 Find the Position of an HTML Element in Scenario Editor Recommended guidance Use element position checks only when a Scenario Editor test truly needs layout validation or coordinate-aware behavior. Prefer stable accessors, labels, and assertions before relying on screen coordinates, because positions can change by browser, device, zoom, responsive layout, or application state. When position matters Verifying that an element is visible inside a viewport or container. Checking scroll behavior, drag targets, or visual placement. Troubleshooting why a click or gesture hits the wrong area. Comparing responsive layouts across browsers or screen sizes. Validation checklist Confirm the element is present, visible, and not covered by another element. Record browser, viewport, zoom, device scale, and Test Node details. Use waits so layout has stabilized before reading position. Avoid hard-coded coordinates unless there is no stable semantic locator. Last updated: October 6, 2026 Add Snapshot Evidence in Scenario Editor Add Snapshot Evidence in Scenario Editor This page replaces old Designer 2.0 wording with current Scenario Editor guidance. Add snapshot evidence when a screenshot or captured state will help diagnose a failure or prove an important business checkpoint. When snapshots help Before and after a critical action. At the first meaningful failure point. When validating layout, displayed data, or a confirmation page. When troubleshooting intermittent behavior across browsers or Test Nodes. Good practices Name the step clearly so the snapshot is easy to find in output. Capture only useful checkpoints; too many snapshots make analysis noisy. Keep sensitive customer data out of screenshots when possible. Attach execution output to the related defect or maintenance note. Last updated: September 9, 2026 Extract Table Content in Scenario Editor Last reviewed: September 21, 2026 Use this article when a Scenario Editor test must read table rows, columns, or specific cell values from a web application. Recommended guidance Prefer stable table selectors and accessible labels when available. Decide whether the test needs one cell, one row, or the full table. Account for pagination, sorting, filters, and lazy-loaded rows. Validation workflow Identify the table and the row/column criteria before extracting values. Use stable locators for headers and cells rather than visual position alone. Normalize whitespace and formatting before comparing values. Validate pagination or scrolling if the expected row is not initially visible. Store extracted values only when they are needed by later steps or assertions. Note: If the application exposes the same data through an API, use that source for setup or cross-checking when appropriate. Last updated: September 21, 2026 If you have feedback on this topic, contact documentation@appvance.ai. How can I wait for an object to disappear? Problem I need to wait until an object disappears. Context My application has reports it generates, and it can take time. When a report is generating, an animated Please Wait image and text appears. Once the report is generated, the page loads and the Please Wait image and text goes away. Solution Option A Wait until the object is no longer visible, but only wait for a maximum amount of time. Notice the not (!) negating the isVisible statement. Action Accessor Wait 60000,!(isVisible(paragraph("Please Wait"))) Option B If you want to wait, as well as check something else while waiting, you could use .wasNotFound() in a While. Note: The Set Search Retries lowered to and then restored after the While completes. Action Accessor Set Search Retries 2 While !(paragraph("Please Wait").wasNotFound()) Wait 1000 End While Set Search Retries 12 Last updated: June 02, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Return the Current Date in a Specified Format You can use the following function to return the current date in a specific format. The example below returns the date in the following format: DD-MMM-YYYY For example: 24-Aug-2026 Example function datefunc() { var monthNames = new Array( "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" ); var date = new Date(); var day = date.getDate(); if (day < 10) { day = "0" + day; } var month = date.getMonth(); var year = date.getFullYear(); var formattedDate = day + "-" + monthNames[month] + "-" + year; return formattedDate; } var currentDate = datefunc(); log(currentDate); How It Works The function uses the JavaScript Date object to retrieve the current date. getDate() returns the day of the month. getMonth() returns the month as a zero-based value ( 0 for January through 11 for December). getFullYear() returns the four-digit year. The month number is used to retrieve the corresponding abbreviated month name from the monthNames array. A leading zero is added to the day when necessary. For example, if the current date is August 24, 2026, the function returns: 24-Aug-2026 Changing the Date Format You can modify the formattedDate expression to return a different format. For example, to return YYYY-MM-DD: var formattedDate = year + "-" + (month + 1) + "-" + day; To return DD/MM/YYYY: var formattedDate = day + "/" + (month + 1) + "/" + year; Note: getMonth() returns a zero-based month value. Therefore, add 1 when using the numeric month directly in the formatted date. Last updated: August 24, 2026 If you have any feedback on this topic, please contact us at documentation@appvance.ai. EnterKey Event in Sahi. Below is the sample code snippet to work with EnterKey. var $storedVars = new Array(); _sahi.robot = new java.awt.Robot(); Sahi.prototype._typeNativeKeyCode = function(keyCode){ this.robot.keyPress(keyCode); this.robot.keyRelease(keyCode); }; _navigateTo("http://sahitest.com/demo/training/login.htm"); _setValue(_textbox("user"),"test"); _setValue(_password("password"),"secret"); _sahi._typeNativeKeyCode(java.awt.event.KeyEvent.VK_ENTER); _wait(10000); Since Key events happens at OS level, Please make sure that your app under test is active while re-playing the test. Last updated: March 09, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Designer: file:// Protocol Support Issue Appvance Designer does not support automating pages opened directly using the file:// protocol. Solution To automate a local HTML page with Designer, serve the page through a web server instead of opening it directly with the file:// protocol. Start a web server that serves the directory containing your HTML pages. Open the page using its HTTP or HTTPS URL, for example: http://localhost:8080/index.html Open the page in Designer using the web server URL. Create or run your automation against the page served through HTTP/HTTPS. Note: Opening the page directly from the local file system using a URL such as file:///C:/path/to/page.html is not supported for Designer automation. Last updated: August 19, 2026 If you have any feedback on this topic, please contact us at documentation@appvance.ai. Date Functions and Formatting in Scenario Editor Last reviewed: September 21, 2026 Use this article when Scenario Editor tests need to generate, transform, or validate dates. Make date handling explicit to avoid timezone and locale issues. Recommended guidance Define the expected input and output date formats before scripting. Use consistent timezone assumptions across test data and application UI. Avoid hard-coded dates unless validating a fixed historical record. Validation workflow Identify whether the value is generated by the test, read from the UI, or returned by an API. Normalize date strings before comparing values. Parameterize offsets such as today, tomorrow, or end-of-month. Validate edge cases around month boundaries, leap years, and daylight-saving changes when relevant. Log both raw and formatted values when troubleshooting failures. Note: Use “Scenario Editor” in current documentation instead of older Test Designer naming where the workflow applies to current AIQ. Last updated: September 21, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Shadow DOM Settings for Scenario Editor Tests Recommended guidance Shadow DOM can hide application elements behind component boundaries, which affects how Scenario Editor identifies and interacts with controls. Review Shadow DOM settings when selectors work on normal pages but fail inside web components. When to review these settings Elements are visible but cannot be found during playback. Recorded locators are unstable inside custom components. Self-healing chooses a similar element outside the intended component. The application framework changed and moved elements into shadow roots. Maintenance workflow Confirm the target element is inside open or closed Shadow DOM. Use stable labels, accessible names, or application-provided test attributes when possible. Validate the selector in the same browser and Test Node used by the scenario. Update waits and assertions so the component is ready before interaction. Document Shadow DOM dependencies that may break after front-end framework changes. Last updated: October 6, 2026 Grant Microphone Permissions for Scenario Editor Tests Last reviewed: October 2, 2026 Use this article when a Scenario Editor test must interact with a browser workflow that requests microphone access. What changed in this article Replaced generic permission wording with Scenario Editor and browser permission setup guidance. Added checks for browser profile, test environment policy, HTTPS requirement, permission persistence, and evidence capture. Clarified that production user microphone prompts should not be handled with personal accounts or real user data. Validation workflow Confirm the test environment is approved to use microphone access and does not capture sensitive audio. Preconfigure the browser profile or test policy so the permission behavior is deterministic. Run the scenario and verify the permission state, browser prompt behavior, and resulting evidence. Review note: This page now treats microphone access as a controlled browser-permission setup task. Last updated: October 2, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Capture the Current Application URL in Scenario Editor Capture the Current Application URL in Scenario Editor Capture the current URL when a Scenario Editor test needs to verify navigation, store a deep link, or include location evidence in execution output. Recommended guidance Use URL validation for navigation outcomes, redirects, or route-specific behavior. Avoid hard-coding environment-specific hosts in reusable scenarios. Compare only the stable URL parts needed by the test. Mask or avoid logging sensitive query parameters. Validation workflow Navigate to the target flow. Wait for the page to finish loading or for a stable route marker. Capture the current URL. Validate the expected path, domain, or parameter according to the test objective. Last updated: September 20, 2026 Get All Dropdown Values in Scenario Editor Last reviewed: September 21, 2026 Use this page when a Scenario Editor test needs to capture and validate the available options in a dropdown or select control. Recommended guidance Confirm whether the control is a native select element or a custom dropdown. Open custom dropdowns before collecting visible options. Normalize labels before comparing expected and actual values. Validation workflow Locate the dropdown using a stable label or selector. Expand the dropdown if options are rendered only after interaction. Collect the option labels and values. Compare the set against expected data, allowing for intentional ordering rules. Close the dropdown and continue the workflow only after validation passes. Note: Dynamic dropdowns may depend on previous selections, user role, or environment data; include that context in the test. Last updated: September 21, 2026 If you have feedback on this topic, contact documentation@appvance.ai. How to get hidden elements from DOM? Steps: Open the application in the chrome browser Inspect the element Go to the console tab Paste this code : javascript:(function(){var newScript = document.createElement('script'); newScript.type = 'text/javascript; newScript.src = '//ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js'; document.getElementsByTagName("head")[0].appendChild(newScript);})(); setTimeout(function(){ console.log($('#ELEMENT_Attribute').html());},18000); Mouse over on the element and wait Last updated: June 02, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai How to Generate a Random Number Within a Given Range You can use the following JavaScript expression to generate a random integer within a specified range, including both the minimum and maximum values: var $randomnumber = Math.floor(Math.random() * ($maximum - $minimum + 1)) + $minimum; For example, the following code generates a random integer between 3 and 7: var $randomnumber = Math.floor(Math.random() * (7 - 3 + 1)) + 3; The generated value can be 3, 4, 5, 6, or 7. The random value can then be used in a Test Designer action. For example: _highlight(_link($randomnumber, _near(_span("Smart Account")))) This approach is useful when test scripts need to select or interact with different values dynamically during execution. Last updated: August 21, 2026 If you have any feedback on this topic, please contact us at documentation@appvance.ai Format Dates for Scenario Editor Tests Format Dates for Scenario Editor Tests Use date formatting when a Scenario Editor test needs to enter, compare, or validate dates in the format expected by the application under test. Recommended guidance Confirm the expected date format with the application or API contract. Avoid locale assumptions when tests run on different hosts or browsers. Keep generated dates and expected dates in approved test data when possible. Document timezone assumptions for date/time validations. Validation workflow Generate or capture the source date. Convert it to the required display or API format. Use the formatted value in the input, request, or assertion. Validate the application saved or displayed the expected value. Last updated: September 20, 2026 How to Data-Drive Xpaths In some scenarios, the XPath used by an accessor may need to be dynamically generated based on test data. Test Designer supports data-driven XPaths by using variables within the XPath expression. The following example shows how to use a variable as part of an XPath: byXPath("//*[@id='" + $Test + "']") In this example, $Test is replaced with the value provided by the test data, allowing the same accessor to interact with different elements during test execution. Find Rows by Visual State in Scenario Editor Find Rows by Visual State in Scenario Editor Use this guidance when a test needs to identify a table row by visual state, such as highlighted, disabled, selected, warning, or error styling. Recommended guidance Prefer stable data attributes, text, or status fields over raw CSS when available. Use style checks only when the style itself is part of the test objective. Avoid brittle row indexes if the table can sort, filter, or paginate. Document why the visual state matters to the business flow. Validation workflow Locate the table or list container. Filter rows by stable text, attribute, or status indicator. Read the visual state only after the row is visible and stable. Validate the expected row content before taking action. Last updated: September 20, 2026 Extract Numbers from a String in Scenario Editor Extract Numbers from a String in Scenario Editor Use this pattern when a Scenario Editor test needs to capture numeric values from application text, such as prices, IDs, quantities, or decimal values. Recommended guidance Extract only the value required by the validation or downstream step. Preserve decimal points only when the business value requires them. Normalize currency symbols, commas, spaces, and labels before comparison. Store extracted values with clear names when they are reused later. Validation workflow Capture the source text from the page, response, or stored value. Apply the extraction rule to isolate the numeric value. Validate the extracted value against expected test data or business rules. Record the source text and extracted value when troubleshooting failures. Last updated: September 20, 2026 Check Whether a Scrollbar Has Reached the Bottom When working with applications that contain scrollable grids or containers, you may need to scroll through the content until a specific cell becomes visible. The following function checks whether the specified cell is visible. If the cell is not visible, it scrolls the target vertical scrollbar and continues checking until the cell is reached. Note: The scrollbar selector used in this example is specific to the application's DOM structure. The index ( [2]) may need to be adjusted depending on which scrollbar is being targeted. function IsScrollbarAtBottom(VARIABLE) { var totalHeight = 1; var clientHeight = 0; while (totalHeight > clientHeight) { var scrollHeight = _eval( "document.getElementsByClassName('k-scrollbar k-scrollbar-vertical')[2].scrollHeight" ); var intScrollHeight = parseInt(scrollHeight); var scrollTop = _eval( "document.getElementsByClassName('k-scrollbar k-scrollbar-vertical')[2].scrollTop" ); var intScrollTop = parseInt(scrollTop); var offsetHeight = _eval( "document.getElementsByClassName('k-scrollbar k-scrollbar-vertical')[2].clientHeight" ); clientHeight = parseInt(offsetHeight); totalHeight = intScrollHeight - intScrollTop; log("Scroll height: " + intScrollHeight); log("Scroll position: " + intScrollTop); log("Client height: " + clientHeight); log("Remaining height: " + totalHeight); if (isVisible(cell(VARIABLE))) { totalHeight = clientHeight; } else { _eval( "document.getElementsByClassName('k-scrollbar k-scrollbar-vertical')[2].scroll(0,40000)" ); } } } IsScrollbarAtBottom(VARIABLE); How It Works The function performs the following operations: Retrieves the total height of the target scrollbar using scrollHeight. Retrieves the current vertical scroll position using scrollTop. Retrieves the visible height of the scrollbar using clientHeight. Calculates the remaining scrollable height. Checks whether the specified cell is visible using isVisible(cell(VARIABLE)). If the cell is visible, the function stops. If the cell is not visible, the scrollbar is moved down and the check is repeated. The following calculation determines how much content remains below the current scroll position: totalHeight = scrollHeight - scrollTop; Identifying the Target Scrollbar The example uses the following DOM selector: document.getElementsByClassName( 'k-scrollbar k-scrollbar-vertical' )[2] The [2] selects the third matching scrollbar element on the page. This value is application-specific and may need to be changed if the page contains a different number or order of vertical scrollbars. Example To scroll until a specific cell becomes visible: IsScrollbarAtBottom(VARIABLE); Replace VARIABLE with the value used to identify the target cell. Important: Despite the function name, the primary purpose of this implementation is to scroll through a container until the specified cell becomes visible. It should not be considered a generic scrollbar-position API. Generate a Three-Digit Random Number in Scenario Editor Generate a Three-Digit Random Number in Scenario Editor Use generated numeric data when a Scenario Editor test needs a simple unique or variable value. Keep the generation rule easy to understand and validate that the application accepts the expected numeric range. Recommended approach Generate values from 100 through 999 when a true three-digit number is required. Use a DPL or approved helper when the value must be reused across steps. Store the generated value if later validation needs to compare it. Avoid using random values for data that must be repeatable for troubleshooting. Validation workflow Generate the number before the input step. Enter it into the target field. Validate that the application saved or displayed the same value. Capture the value in output when diagnosing failures. Last updated: September 9, 2026 Create Unique Strings in Scenario Editor Scripts Last reviewed: September 28, 2026 Use this article when a Scenario Editor script needs unique values for usernames, emails, order IDs, or other test data. What changed in this article Replaced “designer script” wording with Scenario Editor terminology. Added examples of when to use timestamp, random number, GUID-style value, or DPL-driven uniqueness. Added a warning to avoid unique strings that break downstream cleanup, reporting, or repeatability. Validation workflow Choose the uniqueness strategy based on the system under test and cleanup requirements. Store the generated value if later steps need to reuse it for validation. Run the scenario twice and confirm each run creates a distinct value without breaking assertions. Review note: The page now explains the data strategy, not just a code trick for generating a string. Last updated: September 28, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Call JavaScript Functions from Scenario Editor Last reviewed: September 25, 2026 Use this article when a Scenario Editor test needs to call a custom JavaScript function from JS Edit & Play. What changed in this article Replaced “Test Designer IDE” wording with Scenario Editor terminology. Corrected the old typo “Fist step” and clarified that Include loads the script before customJS calls the function. Separated examples for DPL-driven parameters, hard-coded parameters, and values captured with Store/getText so users can choose the right call pattern. Validation workflow Add the JavaScript file with Include before calling the function. Call the function with customJS and pass parameters from DPL, constants, or captured variables. Replay the step in JS Edit & Play and then run the scenario to confirm the function executes in context. Review note: Kept the article as useful Scenario Editor guidance, but modernized the naming and parameter examples. Last updated: September 25, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Data-Drive Wait Values in Scenario Editor Data-Drive Wait Values in Scenario Editor Use data-driven wait values only when different test data genuinely requires different timing. Prefer conditional waits based on application state whenever possible. When data-driven waits make sense Different workflows have documented processing windows. External systems return at different approved polling intervals. The timing value is part of the test data model and needs traceability. Good practices Store timing values in an approved DPL or test data source. Use clear field names such as waitTimeoutSeconds or pollingIntervalSeconds. Set maximum limits so bad data does not create excessive waits. Review repeated wait failures before increasing data-driven timing values. Last updated: September 9, 2026 Validate Scrolling Reaches the Bottom of a Page Validate Scrolling Reaches the Bottom of a Page Use this pattern when a Scenario Editor test must confirm that the browser reached the bottom of a page, list, or scrollable container. This is common for lazy-loaded content, terms pages, infinite scroll, or long result lists. Recommended checks Validate a stable element that appears only near the bottom. Check that lazy-loaded content has finished loading before continuing. Use a container-specific check if the page has multiple scrollable areas. Avoid assuming that one scroll action always reaches the bottom on every viewport. Validation workflow Scroll toward the target area. Wait for the expected bottom marker, footer, or final item. Assert that the expected element or content is visible. Capture output if the page continues loading or the target never appears. Last updated: September 9, 2026 How to escape special characters in Designer What do we do when we encounter a special character and we have to assert it in a designer script ? Lets take the below Example: User navigates to the Apple website and tries to do a assert on iphone page and finds that the iphone 7 has special character " just before 7. So the user now has to assert iPhone"7 which contains a special character just before 7. We can "\" to escape the special character and run the script successfully. For characters that are usually treated specially, '\' indicates that the next character is not special and should be interpreted literally. Last updated: June 26, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Close Browser Windows in Scenario Editor Close Browser Windows in Scenario Editor Use this guidance when a Scenario Editor test opens a second browser window, tab, or popup and must return to the main application flow. Keep window handling explicit so the test does not continue in the wrong context. Recommended workflow Trigger the action that opens the new window or tab. Wait for the expected window, tab, or popup to be available. Validate or capture the needed content. Close the secondary window and switch back to the original context. Validate that the next step runs in the intended page. Good practices Use clear step names that identify the window being handled. Avoid relying on window order if titles or URLs can be validated. Capture output when popup behavior fails or is blocked by the browser. Last updated: September 9, 2026 Manage Multiple DPL Data Sources in Scenario Editor Manage Multiple DPL Data Sources in Scenario Editor Use multiple DPL data sources only when a scenario needs clearly separated data sets, such as users, accounts, products, or generated values. Recommended guidance Name each DPL according to the business data it provides. Keep credentials and environment values out of DPL files and documentation. Document how rows advance, reset, or relate across data sources. Use the smallest data set that validates the test objective. Validation workflow Identify each data source required by the scenario. Map DPL fields to Scenario Editor inputs or validations. Run a small validation execution to confirm row consumption behavior. Review output before scaling or scheduling the suite. Last updated: September 20, 2026 Handle Website Pop-Ups in Scenario Editor Last reviewed: September 21, 2026 Use this article when Scenario Editor tests encounter browser dialogs, modal windows, permission prompts, or application pop-ups. Recommended guidance Identify whether the popup is a browser dialog, application modal, new tab, or permission prompt. Avoid fixed sleeps; wait for the popup condition that matters. Do not automatically grant browser permissions unless the test case explicitly requires it. Validation workflow Trigger the action that opens the popup in a controlled step. Wait for the specific dialog, modal, tab, or message to appear. Validate the popup text or state before interacting with it. Accept, dismiss, or close the popup according to the test objective. Return focus to the main workflow and verify the expected page state. Note: Older “Designer” wording has been replaced with Scenario Editor terminology. Last updated: September 21, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Validate Toast Messages in Scenario Editor Validate Toast Messages in Scenario Editor Toast messages are often temporary, so Scenario Editor tests should wait for them intentionally and capture their text before they disappear. Recommended guidance Use a conditional wait for the toast to appear. Capture only the message needed for the validation. Avoid fixed sleeps unless timing itself is the test objective. Handle success, warning, and error toasts as distinct outcomes. Validation workflow Trigger the application action that produces the toast. Wait for the toast container or message text to appear. Validate the expected message or status. Capture output if the toast does not appear or disappears too quickly. Last updated: September 20, 2026 Parameterize File Uploads in Scenario Editor Parameterize File Uploads in Scenario Editor Use parameterized file uploads when a scenario needs to upload different approved test files across executions or data rows. Recommended guidance Store upload files in an approved location available to the execution host. Use DPLs or test data fields to choose the file path or file name. Avoid using personal, production, or sensitive files as test data. Validate that the application accepted the uploaded file. Validation workflow Prepare approved files and file-path data. Map the file reference into the Scenario Editor upload step. Run a small validation execution. Review output and application evidence for upload success or failure. Last updated: September 20, 2026 Read and Write CSV Rows for Scenario Editor Data Read and Write CSV Rows for Scenario Editor Data Use CSV files as controlled test data sources when Scenario Editor tests need repeatable rows of input or expected values. Recommended guidance Keep CSV headers clear and stable. Document whether rows are consumed once, reused, or reset between runs. Avoid writing sensitive runtime data to shared CSV files. Prefer DPL-managed data behavior when available. Validation workflow Prepare a small CSV sample with known rows. Map fields to Scenario Editor inputs and validations. Run a validation execution and confirm row usage. Review generated or updated rows before using the data in larger runs. Last updated: September 20, 2026 Normalize Extra Spaces in Scenario Editor Values Normalize Extra Spaces in Scenario Editor Values Normalize spacing when application text contains inconsistent whitespace that would otherwise make validations fragile. Recommended guidance Trim leading and trailing spaces before comparison. Collapse repeated spaces only when the business value does not require exact formatting. Keep the original captured value in output when troubleshooting. Avoid normalizing away meaningful spaces in codes, names, or formatted identifiers. Validation workflow Capture the source text. Normalize the whitespace according to the validation need. Compare the normalized value to expected data. Record both original and normalized values when diagnosing failures. Last updated: September 20, 2026 Retrieve Page Elements in Scenario Editor Retrieve Page Elements in Scenario Editor Retrieve page elements when a test needs to validate a list, count results, inspect repeated controls, or choose a dynamic item. Recommended guidance Prefer stable locators and semantic attributes over visual position. Scope element retrieval to the smallest useful container. Avoid collecting every page element unless the test objective requires it. Document how empty, hidden, or disabled elements should be handled. Validation workflow Wait for the page or container to be stable. Retrieve the target element collection. Filter the collection by text, attribute, state, or index only when appropriate. Validate the expected count or selected element before taking action. Last updated: September 20, 2026 Retrieve Numeric Values from Text Retrieve Numeric Values from Text Use numeric extraction when a Scenario Editor test needs a number from text that also includes labels, symbols, or other characters. Recommended guidance Decide whether decimals, negative signs, or separators should be preserved. Normalize the extracted value before comparing it with expected data. Avoid losing leading zeroes when they are meaningful identifiers. Capture the original text for troubleshooting. Validation workflow Read the source text from the page, response, or stored value. Apply the numeric extraction rule. Validate the number against expected data or a range. Store the number if later steps need to reuse it. Last updated: September 20, 2026 Extract Text Between Delimiters in Scenario Editor Extract Text Between Delimiters in Scenario Editor Use delimiter-based extraction when the value needed by a test appears between two stable characters or strings. Recommended guidance Confirm the start and end delimiters are stable across environments. Handle missing or repeated delimiters predictably. Trim only whitespace that is not part of the expected value. Avoid delimiter extraction when a structured field or locator is available. Validation workflow Capture the source text. Identify the start and end delimiters. Extract and normalize the value. Validate the extracted value or store it for later steps. Last updated: September 20, 2026 Legacy Sahi Logging Guidance Legacy Sahi Logging Guidance Sahi-based logging is legacy content. Keep this article only as a migration reference for older assets; current Scenario Editor tests should use AIQ output, logs, and execution evidence instead. Recommended guidance Do not use Sahi logging guidance for new Scenario Editor tests. Retain old logging details only when maintaining a legacy test that cannot yet be migrated. Use current AIQ output and Test Node logs for supported troubleshooting. Mark legacy Sahi dependencies for migration or removal. Validation workflow Identify whether the failing asset still depends on Sahi. Collect current AIQ execution output first. Use legacy Sahi notes only if required to support the old asset. Document the migration path to supported Scenario Editor behavior. Last updated: September 20, 2026 Trim Text Values in Scenario Editor Trim Text Values in Scenario Editor Trim text values when leading or trailing whitespace would make a validation or data mapping unreliable. Recommended guidance Trim only whitespace that is not meaningful to the business value. Normalize values consistently before comparison. Keep the original value visible in output when troubleshooting. Avoid trimming IDs, codes, or fixed-width values unless approved. Validation workflow Capture the source text. Apply trim or normalization logic. Compare the cleaned value with expected data. Store the cleaned value if downstream steps need it. Last updated: September 20, 2026 Use Custom JavaScript Helpers in Scenario Editor Use Custom JavaScript Helpers in Scenario Editor Use custom JavaScript helpers only when a reusable function is needed and the behavior cannot be expressed clearly with standard Scenario Editor steps. Recommended guidance Keep helper functions small, named clearly, and scoped to reusable logic. Do not embed credentials, tenant URLs, or environment-specific values in helper files. Version helper files with the scenario or project maintenance process. Prefer built-in Scenario Editor capabilities when they are sufficient. Validation workflow Define the helper function and expected inputs. Validate it with a small controlled example. Call it from the scenario where the reusable behavior is needed. Review output and failures before using it in larger suites. Last updated: September 20, 2026 Validate Video Playback in Scenario Editor Validate Video Playback in Scenario Editor Validate video playback when the application behavior depends on media loading, playback state, or user interaction with a video component. Recommended guidance Confirm whether the test needs to validate playback start, progress, completion, or UI controls. Use stable player state or visible indicators when available. Account for browser autoplay and permission policies. Avoid long fixed waits when player state can be checked directly. Validation workflow Load the page and wait for the video component. Start playback through the supported UI action. Validate the expected playback state or progress marker. Capture output if playback fails due to media, browser, or network issues. Last updated: September 20, 2026 Verify Checkbox Checked and Unchecked States Last reviewed: September 28, 2026 Use this article when a Scenario Editor validation needs to confirm whether a checkbox is selected or cleared. What changed in this article Cleaned up the title punctuation and changed it into a direct validation task. Added guidance to validate checkbox state through the DOM/property value instead of relying only on visual appearance. Added caution for custom checkbox controls where aria-checked, checked, class names, or hidden inputs may differ. Validation workflow Inspect whether the checkbox is native HTML or a custom UI control. Validate the correct state attribute or property for checked/unchecked behavior. Replay the step after toggling the checkbox both ways to confirm the assertion fails and passes correctly. Review note: Added custom-control guidance because modern web apps often style checkboxes in ways that hide the real state. Last updated: September 28, 2026 If you have feedback on this topic, contact documentation@appvance.ai. How to verify Sorting Functionality You can use a JavaScript function to verify whether the values displayed in a table are sorted in ascending or descending order. The following example retrieves the values from a table column, stores them in an array, and compares each value with the next value to determine the sorting order. function Sortingverify() { var rowlength = _eval("ds$('tbody tr').length"); log(rowlength); var i = 0; var values = []; while (i <= rowlength - 1) { var cellClassName = "slds-truncate uiOutputTextArea[" + i + "]"; assertExists(span(cellClassName)); values.push(getText(span(cellClassName))); i = i + 2; } log("Number of values: " + values.length); if (values.length > 0) { sortCheck(values); } } function sortCheck(arr) { var ascending = true; var descending = true; for (var i = 0; i < arr.length - 1; i++) { log("Comparing: " + arr[i] + " and " + arr[i + 1]); if (arr[i] > arr[i + 1]) { ascending = false; } if (arr[i] < arr[i + 1]) { descending = false; } } if (arr.length == 1) { log("Only one row exists."); } else if (ascending && !descending) { log("Ascending order."); } else if (descending && !ascending) { log("Descending order."); } else if (ascending && descending) { log("All values are the same."); } else { log("Values are not sorted."); } } How it works The script determines the number of rows in the table. It retrieves the values from the target column and stores them in an array. Each value is compared with the following value. The script determines whether the values are: Ascending — each value is less than or equal to the next value. Descending — each value is greater than or equal to the next value. All the same — all values are identical. Not sorted — the values do not follow a consistent order. For example: Apple Banana Orange returns: Ascending order. While: Orange Banana Apple returns: Descending order. If the values are: Apple Orange Banana the script reports: Values are not sorted. Note: The i = i + 2 increment is specific to the DOM structure used by the original example. If the target page uses a different HTML structure, the selector and increment may need to be adjusted accordingly. Last updated: August 17, 2026 If you have any feedback on this topic, please contact us at documentation@appvance.ai. Verify Disabled Buttons in Scenario Editor Verify Disabled Buttons in Scenario Editor Verify disabled buttons when the test objective includes validation rules, permissions, workflow state, or required input behavior. Recommended guidance Check the control state after the page or form is stable. Validate why the button is disabled when the business rule matters. Avoid relying only on color if an attribute or state is available. Include a positive check that the button becomes enabled when required fields are valid. Validation workflow Navigate to the state where the button should be disabled. Wait for validation or page updates to finish. Assert the disabled state through a stable property or behavior. Enter valid data and confirm the state changes when appropriate. Last updated: September 20, 2026 Reuse Shared Logic in Scenario Editor Last reviewed: September 21, 2026 Use this article when multiple Scenario Editor tests need to share helper logic, common setup, or reusable validation patterns. Recommended guidance Avoid copying the same helper code into many scenarios. Keep shared logic versioned and reviewed. Document inputs, outputs, and side effects for every shared helper. Validation workflow Identify the repeated logic and decide whether it belongs in a shared helper, DPL, service call, or test template. Store shared functions in the approved project location. Pass parameters instead of hard-coding environment-specific values. Add a small validation scenario to prove the shared helper works. Update dependent scenarios when the shared helper changes. Note: Use shared logic carefully: a broken helper can affect many scenarios at once. Last updated: September 21, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Latency in AssertExists. We need to do load testing of our web page. I have a designer script that checks 30 components on the page using assetExists. Appvance is taking up to 1 second to perform each assert check so using it for load testing is not feasible. The assert check should take microseconds to complete. Response: In an assertexists, Appvance IQ waits until the page is settled to guarantee the element is present. This is so at any load the script is still valid. Last updated: June 02, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Log Specific Errors During Scenario Execution Last reviewed: September 29, 2026 Use this article when a Scenario Editor test needs to capture targeted errors for debugging or reporting. What changed in this article Changed the vague title into an execution logging task. Added guidance for capturing step context, input data, browser state, response details, and assertion messages. Added caution to avoid logging secrets, tokens, passwords, or customer-sensitive payloads. Validation workflow Decide which error condition needs explicit logging and where it occurs in the scenario. Log the minimum useful context: step name, data row, expected value, actual value, and relevant output. Review execution output to confirm the log helps diagnose the failure without exposing sensitive data. Review note: Added data-safety guidance so error logging is useful but not noisy or risky. Last updated: September 29, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Pagination - How to search items in a page with multiple paginations If you want to search for a specificstring, "Testappvance15860" for example, and if is not found then it should click on the next page. The code will search for the string in the page if the string is not found then it will click on the next pagination The Js Code is given below var Job=isVisible(link(Jobname)); var Pagination=2; log(Pagination.toString()); while (Job==false){ click(link(Pagination.toString())); var Job=isVisible(link(Jobname)); var Pagination=Pagination+1; } click(link(Jobname)); Last updated: June 01, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Self-Healing Questions for Scenario Editor Last reviewed: September 30, 2026 Use this article as a focused FAQ for Scenario Editor self-healing behavior, review expectations, and locator maintenance. What changed in this article Replaced Test Designer terminology with Scenario Editor and changed the title into a self-healing FAQ. Added guidance that self-healing suggestions should be reviewed rather than accepted blindly. Clarified that self-healing helps locator drift but does not replace stable locator design, assertions, or functional maintenance. Validation workflow Review the original locator, the suggested healed locator, and the page context before accepting a change. Replay the scenario to confirm the healed locator selects the intended element consistently. Update the scenario or locator strategy if repeated healing indicates unstable application markup. Review note: This article now complements the self-healing support page without duplicating its accessor inventory. Last updated: September 30, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Regular Expression in Appvance Designer. Query: We need a generic statement for the below accessor. cell("AddImage/Attachment for Issue # 40") As in the 40 will be replaced by any random number. Solution: Here are some of the reg ex that you can give a try. cell("AddImage/Attachment for Issue #/") cell("AddImage/Attachment for Issue/") cell("AddImage/") cell("AddImage/Attachment for Issue #/[0-9]/"). Last updated: June 02, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Common Scenario Editor Troubleshooting Tips Last reviewed: September 21, 2026 Use this page as a triage checklist for common Scenario Editor authoring and playback issues. Link to deeper articles when a problem has a dedicated fix. Recommended guidance Start with the exact failure message, step, browser, and environment. Check locator stability, waits, test data, permissions, and browser compatibility. Avoid duplicating fixes that already exist in more specific KB articles. Validation workflow Reproduce the issue in a small run and capture logs/screenshots. Confirm the application is reachable and test data is valid. Review recent scenario changes, shared helpers, and environment changes. Apply the most specific troubleshooting article when available. Update this overview only with general patterns, not one-off fixes. Note: This replaces legacy “Test Designer IDE” wording with current Scenario Editor terminology. Last updated: September 21, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Group Step Statistics at a Higher Summary Level Last reviewed: September 28, 2026 Use this article when execution results need grouped step statistics for easier analysis and reporting. What changed in this article Rewrote the title for clarity and made the purpose about grouped result analysis. Added guidance on grouping related steps by business transaction, flow, or validation section. Added a warning that grouping should not hide critical step-level failures or timing outliers. Validation workflow Identify which steps belong to the same business action or transaction. Apply grouping/naming consistently before running the scenario. Review both grouped statistics and individual step details after execution. Review note: The page now balances summary-level reporting with the need to preserve detailed failure evidence. Last updated: September 28, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Test Designer 3: HTML5 and Web Application Compatibility Test Designer 3 supports modern HTML5-based web applications and many of the technologies commonly used to build interactive web applications. HTML5 introduced new HTML elements, attributes, APIs, and browser behaviors, while the broader modern web platform includes technologies such as JavaScript, CSS, browser APIs, and client-side frameworks. For additional information about HTML and the web platform, see: WHATWG HTML Standard MDN HTML Documentation HTML5 Compatibility Test Designer supports most commonly used HTML5 features. However, compatibility can depend on how an application implements its UI components and JavaScript event handling. Modern web applications can trigger actions through multiple mechanisms. For example, an application may use standard browser events, JavaScript event handlers, CSS pseudo-classes, custom components, or framework-specific event processing. As a result, an action that works with a standard HTML element may behave differently when the same functionality is implemented through a custom component or JavaScript framework. Click Actions Test Designer provides multiple methods for interacting with clickable elements, including click and click2. In most cases, the standard click action is sufficient. However, some applications implement additional JavaScript behavior or custom event handling that may require an alternative click method. For example, an application may perform additional processing through JavaScript or use CSS pseudo-classes and framework-specific event handlers. For more information about CSS pseudo-classes, see the MDN CSS pseudo-classes documentation. If a standard click action does not produce the expected behavior, try the alternative click method or use an action specifically designed for the application's implementation. File Upload HTML5 does not prescribe a single implementation pattern for file-upload interactions across all web applications. Applications may implement file selection using standard HTML elements, JavaScript, custom components, or framework-specific controls. To accommodate these implementations, Test Designer provides multiple setFiles methods. The appropriate method depends on how the application's file-upload component is implemented. If a file-upload action does not work as expected, verify the underlying HTML element and the application's JavaScript implementation, then select the appropriate setFiles method. Authentication Support Test Designer supports the following authentication mechanisms: Basic Authentication NTLM Authentication Cookie-Based Authentication Digest Authentication ADFS with Kerberos Authentication Active Directory Authentication ADFS with NTLM Authentication when ADFS Extended Protection token checking is disabled ADFS with Negotiate Authentication when ADFS Extended Protection token checking is enabled AIQ Authentication Authentication to the AIQ application itself can be configured using: Internal AIQ credentials LDAP authentication, which requires additional configuration These authentication mechanisms are separate from authentication used by the web applications being automated. Record and Playback Considerations Test Designer uses browser instrumentation and injection mechanisms to provide recording and playback capabilities. Certain application security mechanisms can interfere with these capabilities. Man-in-the-Middle Detection Applications or security tools that detect man-in-the-middle (MITM) activity may prevent Test Designer from recording, injecting, or interacting with a page correctly. If an application uses certificate pinning, traffic inspection, or other mechanisms designed to detect intercepted browser traffic, additional configuration may be required. Browser Certificate Validation Test Designer may use certificates as part of its browser instrumentation and traffic interception mechanisms. Depending on the browser and application configuration, certificate validation can prevent a page from loading correctly or cause the browser to display certificate warnings. For example, browsers may reject certificates that do not match the certificate expected for a particular domain. If a page displays an invalid-certificate error when accessed through Test Designer, verify the browser certificate configuration and the application's security policies. JavaScript Framework Support Test Designer 3 has been tested with commonly used JavaScript frameworks and web technologies, including: React AngularJS Angular jQuery ExtJS Bootstrap Support for a framework does not necessarily guarantee compatibility with every application built with that framework. Framework implementations can vary significantly, and applications may use custom components, third-party libraries, proprietary event handling, or newer framework versions that behave differently from the versions originally tested. Compatibility Considerations Although Test Designer is designed to support modern HTML5 applications and commonly used web frameworks, compatibility can depend on several factors, including: Browser version Framework version Application architecture Custom JavaScript event handling Custom web components Security and certificate policies Third-party browser extensions Application-specific DOM behavior Framework-specific event handling New framework releases, major version changes, forks, and highly customized implementations may require additional validation. When an application does not behave as expected, first determine whether the behavior is specific to the application's implementation or to the underlying framework. Support and Feature Requests Appvance continuously evaluates compatibility with modern web technologies and commonly used frameworks. If you encounter a web application that does not behave as expected in Test Designer, provide the relevant application details, the Test Designer action being used, and the observed behavior when submitting a support request. Feature requests and compatibility issues can be submitted through the available Appvance support channels. Last updated: August 25, 2026 If you have any feedback about this topic, please contact documentation@appvance.ai. Use Relative File Paths for Scenario Editor Uploads Use Relative File Paths for Scenario Editor Uploads Use relative file paths only when the execution environment has a controlled project structure and the files are deployed consistently to the Test Node or execution host. Recommended guidance Prefer approved test-data locations over ad hoc local paths. Document the base directory used to resolve relative paths. Keep upload files versioned with the test assets when appropriate. Avoid paths that depend on a specific user profile or workstation. Validation workflow Place the file in the approved project or execution data location. Reference the file using the documented relative path. Run a small validation execution on the target Test Node. Review output if the file cannot be found or uploaded. Last updated: September 20, 2026 Use Looping Patterns Safely in Scenario Editor Use Looping Patterns Safely in Scenario Editor Use loops only when repeated behavior is required and bounded. Current Scenario Editor guidance should avoid unbounded legacy Test Designer loop patterns. Recommended guidance Set clear exit conditions for every loop. Prefer data-driven iteration or suite configuration when available. Protect tests from infinite loops with maximum attempts or timeouts. Log enough context to diagnose which iteration failed. Validation workflow Identify the repeated action and exit condition. Set a safe maximum iteration count. Validate each iteration against expected state. Review output before increasing data size or concurrency. Last updated: September 20, 2026 Using writeCSVFile API in Sahi. Below code example shows how to use writeCSVFile API. _navigateTo("http://localhost:8080/Appvance/login.html"); _setValue(_textbox("username"), "appvance"); _setValue(_password("password"), "appvance"); _click(_submit("Login")); //user function var htmlelement1 = "username"; var value1 = "appvance"; var htmlelement2 = "password"; var value2 = "appvance"; //capture elements and write to CSV var array = [[htmlelement1,value1],[htmlelement2,value2]]; _writeCSVFile(array, "elements1.csv", true); //another way of declaring array and writing to CSV var $datatowrite1 = []; $datatowrite1[0] = [htmlelement1,value1]; $datatowrite1[1] = [htmlelement2,value2]; _writeCSVFile($datatowrite1, "elements.csv", true); _writeCSVFile($data, "userinfo.csv", true); // overwrites data into userinfo.csv To get value of some element below step can be used. var value1 = "_getText(_div("/someclass/"))"; =============================================== writeFile _writeFile("Value", "FilePath"); // appends second line in file Last updated: March 09, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Handle Asynchronous Pop-Ups in Scenario Editor Last reviewed: September 22, 2026 Use this guidance when pop-ups, modals, ads, or focus-stealing elements appear unpredictably during Scenario Editor playback. Recommended guidance Identify whether the interruption is an application modal, browser dialog, new tab, or third-party ad. Prefer explicit waits and conditional handling over fixed sleeps or broad eval workarounds. Validate the expected page state after dismissing or bypassing the interruption. Validation workflow Trigger the workflow step that may produce the popup. Wait for either the popup or the normal next-page condition. If the popup appears, validate it and close or dismiss it according to the scenario objective. Return focus to the expected page element and continue the workflow. Log screenshots and timing when popup behavior is intermittent. Note: Avoid old Designer-specific eval patterns unless Support confirms they are still required for a legacy scenario. Last updated: September 22, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Which JavaScript version is supported? GraalVM JavaScript implements JavaScript as prescribed in the ECMAScript (ECMA-262) specification. It is fully compatible with the ECMAScript 2021 specification (sometimes referred to as the 12th edition or “ES12”). Last updated: March 09, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Browsers Not Listed When Clicking Record Issue When you click Record in Test Designer, the expected browsers are not listed. Solution 1. Verify the browser paths Make sure the browser executable paths configured in Test Designer are correct. Open the config folder in your local Test Designer installation: TestDesigner/NetworkProxy/config Locate and open the global.json file. Find the browser and platform that are experiencing the issue. Verify that the configured browser executable path matches the actual location of the browser executable on your system. If the path is incorrect, update it to the correct browser installation path. 2. Restart Test Designer as Administrator After verifying or updating the browser paths: Close Test Designer. Restart Test Designer using Run as administrator. Click Record and verify that the expected browsers are now listed. Last updated: August 19, 2026 If you have any feedback on this topic, please contact us at documentation@appvance.ai. Make sure the browser paths are correct. Open the /TestDesinger/NetworkProxy/config folder inside the Test Designer local installation and find the global.json. Scroll down and find the browser and platform that is giving problems. Verify that the listed paths for the browser executables are matching the browser program location in your system. Restart Test Designer as Admin. Handle Browser Location Permission Prompts Handle Browser Location Permission Prompts Browser permission prompts can interrupt Scenario Editor executions. Configure location permission behavior intentionally before the run instead of treating the prompt as an ordinary application dialog. Recommended approach Confirm whether the test requires real, mocked, or blocked location behavior. Use approved browser/profile configuration for the execution environment. Document the expected permission state with the scenario or environment notes. Do not grant browser permissions in production or shared environments without approval. Troubleshooting Check whether the prompt is from the browser, the operating system, or the application. Confirm the Test Node browser profile matches the intended permission state. Review output and screenshots when a prompt blocks execution. Prefer environment configuration over fragile click automation on browser prompts. Last updated: September 9, 2026 Validate Downloaded Files in Scenario Editor Validate Downloaded Files in Scenario Editor Use this guidance when a Scenario Editor test downloads a file and needs to confirm that the expected file was created and contains valid content. Recommended guidance Configure the execution environment so downloads go to a known approved location. Validate file name, type, size, and content according to the test objective. Do not rely only on browser download UI. Clean up downloaded files when the execution environment requires it. Validation workflow Trigger the download action. Wait for the file to be available in the configured download location. Validate the expected file attributes or content. Capture evidence in output if the file is missing or malformed. Last updated: September 20, 2026 Self-Healing Support in Scenario Editor Self-Healing Support in Scenario Editor Self-healing can help Scenario Editor recover when a locator changes between runs. AIQ evaluates the recorded locator and available execution evidence to recommend an alternative when supported. Use self-healing as a review aid, not as a substitute for maintaining reliable locators. Validate any proposed change in Scenario Editor before accepting it. Supported actions and locator behavior can vary by AIQ release and browser technology. Consult the release-specific Scenario Editor documentation for the authoritative supported-accessor list. Last updated: September 14, 2026 If you have any feedback on this topic, please contact us at documentation@appvance.ai Authentication Mechanisms in AIQ Tests Recommended guidance Design authentication in AIQ tests so credentials, sessions, tokens, and test accounts are controlled, repeatable, and safe to use. Authentication steps should reflect the application under test and should not expose passwords or tokens in documentation, logs, screenshots, or scenario code. Common approaches UI login through Scenario Editor when the login flow is part of the test objective. Service Suite authentication for API tokens, OAuth flows, or setup calls. Pre-created test accounts with known permissions and reset procedures. Session setup or teardown steps that keep each run independent. Best practices Use dedicated test accounts instead of personal or production accounts. Store secrets in approved secure locations, not in visible steps or shared notes. Validate multi-factor, SSO, captcha, or conditional-access requirements before automation. Clear sessions when tests must start from a known state. Document account role, environment, and cleanup expectations without revealing credentials. Last updated: October 6, 2026 Handle Validation Failures and Continue Scenario Execution Last reviewed: September 30, 2026 Use this article when a Scenario Editor test should record a validation failure, continue safely, and leave clear evidence for review. What changed in this article Rewrote the question-style title into a clear Scenario Editor failure-handling task. Added guidance on soft validation versus hard stop decisions, cleanup actions, screenshots/logs, and result evidence. Clarified that continuing after a failure should be intentional and should not hide defects or corrupt downstream steps. Validation workflow Decide whether the validation failure is safe to continue past or should stop the scenario immediately. Capture evidence such as message text, screenshot, output log entry, or response payload before continuing. Add cleanup or guard steps so later actions do not depend on a failed state. Review note: This page now explains controlled continuation instead of simply bypassing failures. Last updated: September 30, 2026 If you have feedback on this topic, contact documentation@appvance.ai. How can use a wild card when part of the identifier is always changing? Question How can I use a wild card when part of the identifier is always changing? How can I find an object, if part of the name is always changing? Resolution A quick way to work with accessors, or objects where a portion of the name or attribute is dynamic, is to use the Fuzzy Logic syntax. By simply enclosing the string in quotes with [ ], AIQ will treat that portion as a contains search, and not require a complete match. Read more about Fuzzy Logic in our documentation Example 1 Given an object recorded as span("person testuser") Where testuser matches the name of the logged in user The Fuzzy Logic syntax would be span(["person"]) Example 2 Given a link generated as link("http://test.someurl.com/abc123") Where abc123 matches the a unique resource ID The Fuzzy Logic syntax would be link(["http://test.someurl.com/"]) Need more complex pattern matching? Learn how to use Regular Expressions here Last updated: June 02, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Use Custom getName Methods for SmartTags Last reviewed: September 21, 2026 Use this page when custom naming logic is needed for SmartTags or generated element names. Keep naming deterministic so tests remain readable and maintainable. Recommended guidance Use a custom getName method only when default names are not descriptive enough. Keep generated names stable across runs. Avoid including sensitive data in generated names or logs. Validation workflow Identify which element or object needs a clearer generated name. Define a getName method that returns concise, unique, and stable text. Handle missing or unexpected attributes safely. Test the naming logic against representative elements. Document the naming convention so future maintainers understand it. Note: If SmartTags are not used in the current workflow, mark this page as a legacy reference during future consolidation. Last updated: September 21, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Maximizing the number of concurrent browsers For performance testing, you can increase the number of concurrent Chrome browsers that can run on an AIQ Test Node by optimizing the node's compute and storage resources. The maximum number of concurrent browsers depends on the application under test, the complexity of the test, browser activity, available CPU and memory, and storage performance. As a general starting point, an AWS EC2 node using standard EBS storage may support approximately 20 to 30 concurrent Chrome browsers. Higher concurrency can be achieved by using EC2 instance types that provide local NVMe SSD instance storage and by configuring AIQ to use that storage. Important: These numbers are guidelines, not fixed limits. The appropriate browser count must be determined through performance testing with the application under test. Using NVMe SSD Instance Storage Storage I/O can become a bottleneck when running a large number of concurrent browsers. Browser processes generate significant disk activity, including cache and temporary-file operations. AWS EC2 instance types such as the m6id family include local NVMe SSD instance storage. For example, current AWS specifications list: m6id.2xlarge: 8 vCPUs, 32 GiB memory, 474 GB NVMe SSD m6id.4xlarge: 16 vCPUs, 64 GiB memory, 950 GB NVMe SSD These NVMe SSD volumes provide substantially higher I/O performance than typical baseline EBS configurations. Important considerations NVMe instance storage is ephemeral. Data stored on an instance store volume persists only for the lifetime of the associated EC2 instance. It should therefore be treated as temporary working storage rather than permanent storage. AIQ files, configuration files, or other data that must survive an instance stop or termination should remain on persistent storage. Because the NVMe storage is not persistent, the node must prepare the storage and copy the required AIQ files to it each time the instance is initialized. Configuring AIQ to Use NVMe Storage The recommended setup uses an initialization script, such as nvme_setup.sh, to prepare the performance node. The script should: Detect and mount the available NVMe instance-store device. Copy the GraalVM installation to the NVMe storage. Copy the aiq_distribution directory to the NVMe storage. Configure Chrome to use a local cache directory on the NVMe storage. Start AIQ from the NVMe storage. The Chrome configuration can be added to: aiq_distribution/NetworkProxy/config/global.json Add the following configuration: { "name": "experimentalDS3", "value": "--disk-cache-dir=cache||--disk-cache-size=1" } This configuration redirects the Chrome disk cache to the local storage used by the AIQ node. Setting Up an AWS EC2 Performance Node 1. Prepare the NVMe setup script Add the nvme_setup.sh script to the AIQ distribution on the EC2 instance. The script should detect the available NVMe instance-store volume, mount it, and copy the required AIQ and GraalVM directories to the local storage. The original script assumes that AIQ is installed in: /opt/aiq/aiq_distribution If AIQ is installed in another location, update the script accordingly. Note: The exact NVMe device name can vary between EC2 instance types and operating systems. The setup script should detect the device rather than assuming a fixed device name. 2. Configure Chrome disk caching Modify: aiq_distribution/NetworkProxy/config/global.json Add: { "name": "experimentalDS3", "value": "--disk-cache-dir=cache||--disk-cache-size=1" } The cache directory should reside on the NVMe-backed AIQ installation. 3. Start AIQ using systemd For Linux performance nodes, start AIQ through a systemd service rather than /etc/rc.local. Using systemd also allows you to increase operating-system resource limits. This is particularly important when running many concurrent browsers because the default per-process file descriptor limit may be too low. Create: /etc/systemd/system/appvance.service Use the following configuration and adjust the paths and Java version for the environment: [Unit] Description=Start Appvance IQ services After=syslog.target [Service] Environment=PATH=/opt/graalvm-ce-java11-21.3.3.1/bin:/sbin:/bin:/usr/sbin:/usr/bin Environment=JAVA_HOME=/opt/graalvm-ce-java11-21.3.3.1 User=ec2-user Type=simple LimitNOFILE=10000000 LimitNPROC=20000 ExecStart=/bin/bash /opt/aiq/aiq_distribution/TestNode/nvme_setup.sh WorkingDirectory=/opt/aiq/aiq_distribution/TestNode TimeoutStartSec=0 [Install] WantedBy=multi-user.target Note: Verify the Java/GraalVM version and installation path before using this configuration. The paths above are examples from the original configuration and may not match the AIQ version installed on your node. After creating the service, run: sudo systemctl daemon-reload sudo systemctl enable appvance sudo systemctl start appvance To verify the service: sudo systemctl status appvance The original article contains a typo ( systemclt enable). The correct command is: systemctl enable appvance Resource Limits When increasing browser concurrency, make sure the operating system can support the required number of processes and open files. The example service uses: LimitNOFILE=10000000 LimitNPROC=20000 These values are intentionally high and should be validated against the requirements of the specific environment. Increasing limits does not by itself guarantee higher browser concurrency; CPU, memory, storage I/O, network capacity, and the application under test can all become bottlenecks. Example Concurrency Results The original performance testing produced the following results: EC2 Instance Concurrent Chrome Browsers m6id.2xlarge 40 m6id.4xlarge 80 These results were obtained with a Test Designer test case and should be treated as example performance results rather than guaranteed capacity. Actual concurrency can vary depending on: Application complexity Number and type of requests generated by each browser JavaScript execution Browser memory consumption CPU utilization Network traffic Test data AIQ configuration Chrome version Operating-system configuration Storage performance For this reason, perform a capacity test before selecting the final number of concurrent browsers for a performance environment. Amazon Linux Version The original version of this article specifically targeted Amazon Linux 2. Amazon Linux 2 reached end of life on June 30, 2026. AWS recommends migrating to Amazon Linux 2023. Therefore, new performance nodes should use an AWS-supported operating system and the corresponding AIQ installation and startup configuration. If an existing environment still uses Amazon Linux 2, treat the configuration in this article as a legacy setup and plan migration to Amazon Linux 2023. EBS Storage Considerations EBS performance depends on the volume type and its provisioned performance. For example, Amazon EBS gp3 volumes provide a baseline of 3,000 IOPS and 125 MiB/s throughput, with additional IOPS and throughput available through provisioning. Therefore, the storage bottleneck should not be described simply as a limitation of a "60 GB EBS volume." When investigating concurrency limitations, monitor the actual EBS IOPS, throughput, latency, and utilization of the node. For workloads that generate substantial browser disk activity, local NVMe instance storage can be an effective way to reduce EBS-related storage contention. Troubleshooting and Capacity Testing If increasing the number of browsers causes execution failures or significantly longer response times, monitor the following resources during the test: CPU utilization Memory utilization EBS IOPS and throughput NVMe utilization Disk latency Network utilization Number of open files Number of running processes Chrome memory consumption AIQ/Test Node logs Increase concurrency gradually rather than immediately configuring the maximum expected browser count. For example: 20 browsers → 40 browsers → 60 browsers → 80 browsers At each level, verify that the node remains stable and that response times and error rates remain within the requirements of the performance test. Last updated: September 2, 2026 If you have any feedback on this topic, please contact us at documentation@appvance.ai. Understand Step Duration Calculations in Scenario Editor Last reviewed: September 29, 2026 Use this article to choose and interpret AIQ step-duration metrics such as DOM Complete, Server Response Complete, Full Page Loaded, Script Time, Ajax Time, and Next Step Ready. What changed in this article Replaced Test Designer/Web Designer wording with Scenario Editor terminology while keeping browser PerformanceNavigationTiming context. Clarified which timings come from the browser and which are calculated by AIQ, including the SPA behavior where browser timings may return 0. Added guidance that Script Time is often closer to perceived user duration, while Ajax Time is mostly retained for backward compatibility. Validation workflow Select the timing option that matches the question being answered: browser timing, user-perceived step time, or SPA readiness. Compare AIQ output with browser performance timing only for browser-provided metrics. Document the selected timing option when sharing reports so reviewers interpret duration values correctly. Review note: This update keeps the technical timing distinctions but removes older Designer/Web Designer naming and fixes readability around asynchronous behavior. Last updated: September 29, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Troubleshoot Iteration Summary Error Messages Last reviewed: September 28, 2026 Use this article when an AIQ execution shows an iteration-summary error and the team needs to identify whether it came from data, playback, or reporting. What changed in this article Changed the article from a vague error-message title into a troubleshooting workflow. Added checks for DPL row availability, failed assertions, step-level output, report generation timing, and execution logs. Clarified that the iteration summary is an investigation entry point, not the only source of failure evidence. Validation workflow Open the failed execution and compare the iteration summary with the step output. Check whether the failing iteration maps to a specific DPL row or input value. Review report/output logs before changing the scenario logic. Review note: This now helps triage data-driven iteration failures instead of just naming the error. Last updated: September 28, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Capture and Validate Tooltips in Scenario Editor Last reviewed: September 29, 2026 Use this article when a Scenario Editor test needs to trigger, capture, and validate tooltip text. What changed in this article Replaced Test Designer wording with Scenario Editor terminology. Added guidance to distinguish native title tooltips, ARIA/toolkit tooltips, and custom DOM tooltip components. Added timing and hover/focus validation checks so flaky tooltip assertions are easier to diagnose. Validation workflow Identify whether the tooltip appears on hover, focus, or click and whether it is native or custom HTML. Capture the tooltip text or attribute after the UI has displayed it. Replay the step with timing checks and confirm the assertion fails when expected text changes. Review note: Modernized the tooltip workflow and added custom component handling for current web apps. Last updated: September 29, 2026 If you have feedback on this topic, contact documentation@appvance.ai. How to access two different application at the same time in a single script. Navigate to any URL Eg: https://demosite.appvance.com/ Perform some steps Add new action called “Open Tab” and add a URL “https://www.apple.com/ “ Store any value for any element on the page Use Select Window action and go to 1st URL i.e https://demosite.appvance.com/ Click on the search text field icon on the Appvance Demo site app Use the Variable on the text field which was stored in the Apple website You will be able to search with the created variable in 2nd application User can use Select Window to move Back and Forth in both the applications. Last updated: June 01, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai How to find the X Y Coordinates function alertMousePos(event) { alert( "X: " + event.clientX + " - Y: " + event.clientY); } document.addEventListener("click", alertMousePos); Just copy and paste the above code into the browser’s console and press the ‘Enter’ key. Now click on wherever on the page- An alert will get displayed with x and y values -- It gets the x, and y coordinates of the click of the mouse pointer. Note - Any console (Normal browser or test designer browser) should work, but advisable to use the Test Designer browser in maximized state. Last updated: June 02, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai How to perform Mouse Over action using Toggle Style API From Test Designer We have the below two APIs to perform mouse over from Test Designer Mouse Over Toggle Style MouseOver using Toggle Style Action Add the below step with the accessor which needs to be Mouse over Select API as Toggle Style from the scripts step Add the Accessor which needs to mouse over Add “hover“ in the value column Example Screenshot Last updated: June 01, 2023 If you have any feedback on this topic, please contact us at documentation@appvance.ai Verify Whether a User Exists in the Database Last reviewed: September 29, 2026 Use this article when a Scenario Editor or Service Suite validation needs to confirm whether a specific user record exists in a database. What changed in this article Rewrote the question-style title into a database validation task. Added checks for parameterized queries, database connection settings, permissions, expected row count, and negative-case validation. Added a safety note to avoid logging passwords, tokens, email addresses, or sensitive user attributes from query results. Validation workflow Identify the unique user key to validate, such as username, user ID, or test email. Run a parameterized query through the approved AIQ database/service workflow. Assert the expected row count or field value, then run a negative case to confirm the validation can fail correctly. Review note: The article now focuses on safe database validation instead of a broad yes/no question. Last updated: September 29, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Validate the Color of an Object in Scenario Editor Validate the Color of an Object in Scenario Editor Use this article when a Scenario Editor test needs to confirm the visual color of a page object. Prefer stable CSS or DOM-based validation when available, and use image-based validation only when the rendered appearance is the actual requirement. Recommended guidance Identify whether the requirement is CSS value, computed style, image color, or visual state. Use stable locators and validate the object is visible before checking color. Account for themes, hover/focus states, browser differences, and anti-aliasing. Use tolerances for image or screenshot-based color checks when exact pixels may vary. Capture evidence when a color mismatch indicates a UI regression. Validation workflow Locate the target object and confirm the expected state. Read the CSS/computed value or capture the visual sample, depending on the requirement. Compare against the expected color or accepted range. Log the actual value when validation fails. Last updated: October 9, 2026 MFA Authentication Automation Guidance Last reviewed: September 30, 2026 Use this article to decide how AIQ tests should handle applications protected by multi-factor authentication. What changed in this article Reframed MFA automation around approved test-environment patterns instead of bypassing or weakening MFA. Added guidance for test accounts, pre-authorized sessions, API token flows, IdP test policies, and audit requirements. Added a warning that real user OTPs, personal devices, and production MFA prompts should not be automated in shared tests. Validation workflow Confirm the approved MFA strategy with the application owner or identity team before building the scenario. Use a controlled test account, test IdP policy, or token-based flow that is explicitly approved for automation. Record evidence of the authentication path without logging OTPs, recovery codes, personal phone numbers, or secrets. Review note: This page now treats MFA as a security control to coordinate around, not a popup to defeat. Last updated: September 30, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Create Multiple Orders and Write Order IDs to a Repository CSV Last reviewed: September 30, 2026 Use this article when a Scenario Editor test needs to create multiple records and persist generated order IDs to a repository CSV for later validation or reuse. What changed in this article Shortened and corrected the long title while preserving the order-ID-to-CSV use case. Replaced Test Designer framing with Scenario Editor and repository CSV terminology. Added checks for CSV headers, append versus overwrite behavior, concurrency collisions, cleanup, and sensitive data masking. Validation workflow Create the order records and capture each generated order ID from the response, UI, or service output. Write only the required fields to the repository CSV with a clear header and deterministic file path. Replay the consuming scenario and confirm it reads the expected rows without duplicate or stale IDs. Review note: This page now focuses on the data handoff pattern and calls out concurrency risks when multiple runs write to the same CSV. Last updated: September 30, 2026 If you have feedback on this topic, contact documentation@appvance.ai. Read and Write Data from a Downloaded XLSX File in Scenario Editor Read and Write Data from a Downloaded XLSX File in Scenario Editor Use this article when a Scenario Editor test needs to validate, read, or write data from an XLSX file downloaded during execution. Keep file handling deterministic so repeated runs do not accidentally use stale files. Recommended guidance Download files into a known test-specific folder when possible. Validate the file name, extension, size, and modified time before reading it. Use unique names or cleanup steps to avoid reading an older XLSX from a previous run. Check sheet name, row count, column names, and expected cell values before using the data in later steps. Avoid storing sensitive customer data in downloaded spreadsheets unless the test data has been approved. Validation workflow Trigger the download in Scenario Editor. Wait for the file to exist and confirm it is complete. Read the required workbook, sheet, row, and column values. Write or compare output values only after validating the workbook structure. Last updated: October 8, 2026