Sample questions
Ta Locators Selectors StrategyDifficulty 1
Why is a dedicated data-testid attribute generally preferred over relying on CSS classes to locate elements in automated UI tests?
- aCSS classes are usually tied to styling and change when the design changes, while a
data-testid exists only for testing and stays stable across visual refactors✓ - bBrowsers execute
data-testid lookups faster than any other attribute lookup at the DOM engine level - cCSS classes cannot be selected at all by Selenium, Cypress, or Playwright, since class attribute selectors were removed from all three tools' selector engines
- dA
data-testid attribute is required by HTML5 for every interactive element
Explanation:The correct answer is a: data-testid is a convention created purely for test hooks, so it does not get renamed or removed when a designer reworks the stylesheet, which is exactly what happens to CSS classes tied to styling. b is false — there is no meaningful engine-level speed difference between attribute selectors. c is false, all three tools can select by class and none of them ever removed that capability. d is false, HTML5 has no such requirement.
Ta Locators Selectors StrategyDifficulty 1
What makes a locator like //div[3]/span[2]/a fragile compared to a locator based on a stable attribute?
- aXPath expressions are deprecated in modern browsers and may stop working at any time without any prior warning from the browser vendor
- bIt depends on the exact structural position of elements in the DOM, so any markup reorder or an inserted wrapper
div breaks it✓ - cIt cannot be used in Selenium, only in Playwright
- dPositional XPath always runs slower than any CSS selector, regardless of DOM size
Explanation:The correct answer is b: positional XPath encodes the exact tree structure, so a designer adding one more wrapper element or reordering siblings silently breaks the locator even though the target element itself never changed. a is false, XPath is not deprecated and no browser vendor has announced any such removal. c is false, Selenium supports XPath natively via By.xpath. d is an overgeneralization about performance, not the actual fragility problem.
Ta Locators Selectors StrategyDifficulty 1
In Selenium (Java bindings), which line correctly locates an element by its CSS selector?
- adriver.findElement(By.selector(".submit-btn", SelectorType.AUTO));
- bdriver.querySelector(".submit-btn");
- cdriver.findElement(By.cssSelector(".submit-btn"));✓
- ddriver.findElement(CssSelector(".submit-btn"));
Explanation:The correct answer is c: Selenium's By class exposes By.cssSelector(String) as the factory method for CSS-based locators, used as driver.findElement(By.cssSelector(...)). a invents a non-existent By.selector method and a fabricated SelectorType.AUTO enum that auto-detects CSS vs XPath, which Selenium's By API has no concept of. b invents a querySelector method directly on WebDriver, which does not exist in Selenium's API. d omits the required By. prefix, so it would not compile.
Ta Locators Selectors StrategyDifficulty 1
In Cypress, what is the conventional way to select an element reserved specifically for test automation, following the common data-cy convention?
- acy.get('[data-cy=submit-button]')✓
- bcy.select('data-cy', 'submit-button')
- ccy.locate('data-cy=submit-button')
- dcy.find('#data-cy-submit-button')
Explanation:The correct answer is a: Cypress does not have a dedicated data-attribute API, so the community convention is to use the generic cy.get() with an attribute-selector string, cy.get('[data-cy=submit-button]'). b invents a cy.select command with that signature (Cypress's real .select() is for <select> dropdown options, not attribute lookup). c invents a cy.locate command that does not exist. d misuses an id selector syntax for what is actually an attribute.
Ta Locators Selectors StrategyDifficulty 1
What is the primary motivation behind Playwright's role-based locators such as getByRole('button', { name: 'Submit' })?
- aThey execute faster than CSS selectors because they skip the DOM entirely and query the browser's rendering engine directly
- bThey are the only locator type that works with Shadow DOM elements
- cThey automatically retry failed network requests behind the element
- dThey query the accessibility tree, so tests reflect how the element is exposed to assistive technologies and stay stable even if implementation markup changes✓
Explanation:The correct answer is d: role-based locators query the browser's accessibility tree by role and accessible name, which means the test targets user-facing semantics rather than incidental markup, and both concerns (test stability, accessibility coverage) are addressed together. a is false, they still traverse rendering internals, not a speed shortcut. b is false, Playwright's regular locators already pierce open Shadow DOM. c is unrelated to what role-based locators do.
Ta Locators Selectors StrategyDifficulty 2
A page has several buttons all sharing the class btn btn-primary, and only their visible text differs ("Save", "Cancel", "Delete"). Which locator strategy best avoids ambiguity without adding new markup?
- aSelect by the shared class and always pick the first match returned
- bLocate the button by its visible accessible text, e.g. Playwright's
getByRole('button', { name: 'Save' }) or an XPath/CSS text-based selector✓ - cUse an XPath that counts sibling position among all
.btn elements on the page, assuming their relative order never changes across releases - dSelect by tag name
button combined with the class, since that narrows the result to exactly one element
Explanation:The correct answer is b: since the shared class does not disambiguate, and the visible text is the only distinguishing, stable signal, locating by that text (directly or via role+name) targets the right button regardless of DOM order. a is fragile and semantically wrong — 'first match' happens to work only by coincidence. c reintroduces positional fragility and additionally bakes in an unstated ordering assumption that can silently break. d is wrong because tag+class still matches all three buttons, it does not narrow to one.