Question 1

1. Login Flow (Gherkin / BDD)

Accepted Answer

A standard end-to-end login test. Uses fill, click, and assert actions. Use the exact visible label of the field (e.g. Email, not email_input). The AI matches by visible text and placeholder, not by HTML attribute names.

Question 2

2. Registration Form with Data Table (Gherkin)

Accepted Answer

Fill multiple fields in one step using a data table. Each row is | Field Name | Value |. The table format fills all fields in a single step — ideal for long forms. Column 1 is the field label; column 2 is the value to type.

Question 3

5. TDD Format (Steps with Expected Results)

Accepted Answer

Use TDD format when your test cases have numbered steps and a separate expected result. Start with "Test Case ID:" or "Steps:". The AI auto-detects TDD format when it sees Steps: or Test Case ID:, so there is no need to add Gherkin keywords.

Question 4

7. Advanced Actions — Hover, Double-Click, Key Press

Accepted Answer

The engine supports a full set of interaction types beyond basic fill and click: navigate, click, fill, select, assert, check, uncheck, hover, double_click, right_click, press_key, upload, drag, drag_by_offset, resize, scroll_page, wait, refresh, set_viewport, set_cookie, clear_cookies, clear_storage, set_geolocation, wait_for_response, press_and_hold, click_at_coordinates, mouse_move, zoom, focus, blur and key_combo (keyboard shortcuts such as Ctrl+A, Ctrl+C / Ctrl+V or Ctrl+Shift+S — Ctrl and Cmd both work, on any OS). Script steps (run JavaScript) and Mock steps (answer network requests) are chosen with the step-kind toggle in the editor, and a suite can emulate a device, timezone and locale.

Question 5

8. Browser State, Keyboard Shortcuts and Network Waits (Gherkin)

Accepted Answer

Steps can prepare the browser as well as the page: set or clear cookies, clear local and session storage, set the geolocation, resize the viewport, press keyboard shortcuts such as Ctrl+A or Ctrl+Shift+S, and wait for a named network response. Ctrl and Cmd are interchangeable, so the same test runs on Windows and macOS. There is no step that writes or reads local storage — clear_storage only clears it (or removes one quoted key); use a Script step to set or read a value.

Question 6

9. Script and Mock Steps (Step-Kind Toggle)

Accepted Answer

Every step in the editor has a step-kind toggle: UI, API, Script and Mock. A Script step runs JavaScript in the page as the body of an async function, can save its result as a variable for later steps, can target an iframe, and can fail when it returns false or empty. A Mock step answers matching network requests with a mocked response or a network error, from that step to the end of the test case — place it before the step that sends the request. Script and Mock steps are never inferred from step text; you choose them with the toggle.

Question 7

Run test cases in parallel

Accepted Answer

On the Edit Suite page of a UI Automation suite, the Parallel dropdown sets how many test cases run at once: Parallel: Off, 2 at a time, 3 at a time or 4 at a time. The setting is saved on the suite and used by manual runs, schedules and CI/CD triggers. Each lane gets its own browser. Test cases that log in run first, and every other test case starts from the saved session of the login before it in the suite. Credits are charged per test case executed, so a parallel run costs the same as a sequential one. Parallel runs apply to UI Automation suites; API and Mobile suites run one test case at a time.

Question 8

Localization testing — emulate a device, timezone and locale

Accepted Answer

A UI Automation suite can emulate a device (iPhone 13, iPhone SE, iPhone 14 Pro Max, Pixel 7, Galaxy S9+, iPad Mini, iPad Pro 11), a timezone (for example Asia/Kolkata, Europe/Berlin or America/New_York) and a locale (en-US, en-GB, fr-FR, de-DE, es-ES, it-IT, pt-BR, hi-IN, ar-SA, ja-JP, zh-CN). The locale sets the browser language the page sees (navigator.language and the Accept-Language header); the timezone is what the browser reports to the page. The settings are saved on the suite and applied when each test case's browser starts, for manual, scheduled and CI/CD runs alike. Emulation is one setting per suite with no per-run override, so to cover several locales keep one suite per locale or change the dropdown between runs.

Question 9

Click buttons labelled in Arabic, Hindi, Japanese or Chinese

Accepted Answer

A step can name a button or link by its label in any script, for example I click the "أضف إلى السلة" button, I click the "कार्ट में जोड़ें" button, I click the "カートに入れる" button or I click the "加入购物车" button. Quote the whole label exactly as it appears on screen. For a label in a non-Latin script every word must match: a button that shares only some of the words is not picked by its text. Text checks such as I should see work in any script. The Practice Page's QA Practice Lab has a Localization tab whose Translated Store panel lets you practise this in Arabic, Hindi, Japanese and Chinese.

Question 10

Elements inside Shadow DOM (web components)

Accepted Answer

Controls inside open shadow roots — including nested web components and slotted text — are located, clicked, filled and asserted like any other element. You write the step with the visible label as usual; the engine builds a chained locator with one segment per shadow boundary, for example #shell >> #prefs >> input[type="checkbox"]. Text checks such as "I should see" also read text rendered inside open shadow roots, and cookie banners or dialogs rendered in a shadow root can be dismissed. Controls inside closed shadow roots cannot be targeted by name: the engine detects the closed root and never clicks a look-alike, but the step fails with a general error that does not mention the closed root. Reach such a control with a coordinate click inside the host element or with the keyboard, and assert results shown outside the closed root.

Question 11

SVG icons and icon-only buttons

Accepted Answer

A click on an icon resolves to the real control behind it — the button or link that hosts the SVG — rather than the path inside the glyph. When the SVG element itself is the target, the engine emits namespace-safe XPath such as //*[name()='svg'][@aria-label='Close'], checks that it matches before using it, and applies SVG-aware visibility checks so a hidden icon is not reported as visible. Icon-only controls are named from their aria-label or the SVG's title element.

Question 12

Practise Shadow DOM and SVG on the Practice Page

Accepted Answer

The QAEverest Practice Page (the ShopVerse demo store) has two QA Practice Lab tabs for this. The Shadow DOM tab has an open shadow root form, a checkbox three shadow roots deep, slotted content, a closed shadow root and an icon toolbar whose SVG sits two shadow roots down. The SVG Elements tab has icon-only controls named five different ways, a star rating, a clickable bar and donut chart, and a seat map. Every panel writes its result as ordinary page text, so the outcome is easy to assert. Include the login steps in every test case, because the demo login lasts only for the browser tab that signed in.

Question 13

Check a suite for unclear steps before running it

Accepted Answer

On Edit Suite, every test case carries a readiness badge, and the Check whole suite button reviews all of them at once without starting a run. Specified means every step says what it needs; "2 to answer" means some steps would run without testing what they read as; "Specified · 1 won't run" means a step will not run at all and the report will say so; "Specified · 1 answered" means a step runs on an answer you saved. Saved answers stay on the step for every future run, and the sheet shows them again so you can change or clear them. Answering is optional — the sheet offers Save answers, Answer & run and Run anyway, so a run is never blocked.

Question 14

Repair a step from the result page

Accepted Answer

A failed step has one Step Repair button with four remedies: Edit step (reword it; saved to the test case and used on the next run), Point to Element (pin the right element with Pin locator, or rule the wrong one out), Wait before (hold the step until the page is ready, then Save Wait) and Accept failure (mark it accepted with an internal note). A step that passed can be reworded too, with Edit step.

Question 15

One action per step

Accepted Answer

Each step should perform exactly one browser action. Combining actions in a single step confuses the AI classifier and produces unreliable results.

AVOIDWhen I enter my email, password and click login

PREFER

When I enter "user@test.com" in the "Email" field
And I enter "pass123" in the "Password" field
And I click the "Login" button

Question 16

Name elements by their visible label

Accepted Answer

Use the text the user actually sees on screen — button labels, field placeholders, heading text. Do not use HTML IDs, class names, or developer-facing names.

Question 17

Always set the Base URL before running

Accepted Answer

Go to Environment Settings (the gear icon on the UI Automation page) and add at least one environment with a valid Base URL before creating or running any suite. Without a Base URL, navigation steps have no starting point.

Question 18

Add data-testid attributes to your app

Accepted Answer

Stable data-testid attributes are the single most effective way to improve locator reliability. The AI's Stage D parser prioritises these above all other attributes. Use kebab-case names that describe the element's purpose, not its style.

UI Automation Setup Guide — Complete Reference

Sample Test Cases

Run Settings — Browser, Parallel Runs and Localization

Shadow DOM, SVG and Icon Elements

Glossary

Best Practices

Explore Now!