Selenium · Junior

Selenium Locator and Assertion Interview Questions

Locator strategy, stale elements, absence checks and exact values.

12 questions, each with the answer and the reason every other option is wrong. You can read them here, then sit the timed session to find out what you actually remember.

1. What is the difference between findElement and findElements?

Answer

findElement returns one element or throws if none; findElements returns a list that can be empty

Correct. This also makes findElements the standard way to check absence: an empty array instead of an exception.

Remember the error behavior: findElement throws NoSuchElementException when nothing matches, findElements returns [].

Why the other answers are wrong

  • findElements is only for XPath. Both accept every By strategy.
  • findElement is deprecated. Both are current API.
  • findElements clicks all matching elements. It only returns them; it performs no actions.

2. Your test gets a StaleElementReferenceException. What happened?

Answer

The element was found earlier, but the page re-rendered and that reference no longer points to a live DOM node

Correct. The fix is to find the element again after the page updates, not to reuse old references across renders.

Stale element = you kept a reference across a DOM re-render. Re-locate the element after actions that update the page.

Why the other answers are wrong

  • The selector has a typo. A typo gives NoSuchElementException at lookup time, not a stale reference later.
  • The browser crashed. A crash ends the session with a different error.
  • The element is just slow to load. Slow loading causes lookup timeouts; staleness is about a previously found element being replaced.

3. Which locator strategy should you avoid when possible?

Answer

Long absolute XPath like /html/body/div[2]/div/div[3]/button[1]

Correct. Absolute XPath encodes the whole DOM structure, any layout change breaks it.

Prefer short, meaning-based selectors (id, name, data-testid via CSS). Keep XPath short and relative when you must use it.

Why the other answers are wrong

  • By.css with a data-testid attribute. Dedicated test attributes are the most stable choice.
  • By.id when the id is stable. A stable id is fast and reliable.
  • By.name on form fields. Name attributes on forms are usually stable and fine to use.

4. Why is By.id('save-button') usually the best choice when the id is stable?

Answer

Ids are meant to be unique and rarely change, so the lookup is fast and survives redesigns

Correct. A stable id is the closest thing Selenium has to a guaranteed handle.

Strategy order: a stable id or data-testid via CSS first; structure-based paths last.

Why the other answers are wrong

  • Ids are the only strategy findElement supports. findElement supports css, xpath, name, id and more.
  • By.id can find several elements at once. Ids are unique by definition. One element per id.
  • Ids work without loading the page. Every lookup needs a loaded page. Stability is the reason, not magic.

5. After adding one item, which check proves the cart badge shows exactly 1?

Answer

assert.strictEqual(await badge.getText(), '1')

Correct. Reading the text and comparing the exact value catches a broken counter that still renders the badge.

Read the value with getText() and assert it exactly. Presence and visibility checks pass on a broken counter.

Why the other answers are wrong

  • assert.ok(await badge.isDisplayed()). The badge is displayed whether it shows 0 or 1. Visibility does not check the value.
  • Finding the badge without asserting anything. A lookup proves existence, not correctness. Assert the value.
  • Taking a screenshot. A screenshot records the state; it does not fail the test when the value is wrong.

6. How do you assert that the welcome message did NOT appear after a failed login?

Answer

const found = await driver.findElements(By.css('[data-testid="welcome-message"]')); assert.strictEqual(found.length, 0)

Correct. findElements returns an empty array instead of throwing. The clean absence check.

findElements + length === 0 is the standard absence assertion. Prove the error showed and the dashboard did not.

Why the other answers are wrong

  • findElement inside a try/catch and pass when it throws. It works but is noisy and easy to get wrong. findElements with length 0 says the same thing cleanly.
  • Wait 5 seconds and assume it would have appeared. A sleep plus an assumption is not an assertion.
  • Absence cannot be tested in Selenium. It can, findElements makes absence a simple length check.

7. A field already contains text and sendKeys appends to it. How do you replace the value?

Answer

await field.clear() first, then sendKeys the new value

Correct. sendKeys types into whatever is there; clear() empties the field first.

clear() then sendKeys() is the replace pattern. Forgetting clear() is a classic source of wrong-value bugs in tests.

Why the other answers are wrong

  • Call sendKeys twice. That appends twice. The old text is still there.
  • sendKeys always replaces the value. It appends. That is exactly the bug this question is about.
  • Reload the page between keystrokes. Reloading resets the whole form, not just the field, and restarts the flow.

8. Why is By.css('[data-testid="add-to-cart"]') more reliable than By.css('.btn.btn-primary.large')?

Answer

The test id exists for testing and stays stable; styling classes change with any redesign

Correct. Style classes describe how the element looks today. The test id describes what it is.

Anchor tests to attributes that exist on purpose for testing, not to styling that changes with every redesign.

Why the other answers are wrong

  • Attribute selectors are faster than class selectors. Speed is not the point, stability across UI changes is.
  • Class selectors do not work in Selenium. They work. They are just tied to styling that changes.
  • data-testid is required by the W3C spec. It is a convention teams adopt, not a spec requirement, and that convention is the value.

9. A field already contains 'abc' and you call sendKeys('xyz'). What is in the field afterwards?

Answer

abcxyz, sendKeys appends, so you must call clear() first to replace a value

Correct. Forgetting clear() is a very common source of wrong-value bugs in Selenium tests.

clear() then sendKeys() is the replace pattern. Without clear(), you append.

Why the other answers are wrong

  • xyz, sendKeys always replaces the value. It appends. This is the behaviour that surprises people coming from other tools.
  • The field is cleared and left empty. sendKeys never clears by itself.
  • An error is thrown. No error; you simply get the two values joined.

10. What does driver.navigate().refresh() do that driver.get(currentUrl) may not?

Answer

It reloads the current page as the browser would, keeping the same history entry

Correct. get() performs a fresh navigation, which can behave differently for history and for pages that react to reloads.

Use refresh() when you mean 'reload this page', such as after setting a cookie.

Why the other answers are wrong

  • They are always identical. They are similar but not the same, and history handling differs.
  • refresh() clears cookies. Cookies are unaffected by a refresh.
  • refresh() works only in Chrome. It works in every supported browser.

11. Where should driver.quit() be called so it always runs?

Answer

In an afterEach hook, which runs whether the test passed, failed or threw

Correct. Putting quit() at the end of the test body means a failure skips it, leaving browsers running.

Create the driver in beforeEach and quit it in afterEach. Teardown must survive failures.

Why the other answers are wrong

  • At the end of each test body. A failure earlier in the test skips it, which is how build machines fill with browsers.
  • In a beforeEach hook. That would close the browser before the test uses it.
  • It is optional; browsers close themselves. They do not. Forgotten sessions accumulate until the machine struggles.

12. You need to select 'Customer' from a real <select> dropdown. What is the standard approach?

Answer

Use the Select helper class, choosing by visible text or value

Correct. Select wraps the native element and handles the option selection properly.

Native <select> uses the Select class. Custom dropdowns built from divs are clicked like normal elements.

Why the other answers are wrong

  • Click the select, then click the option like any other element. That can work for custom dropdowns but is unreliable for a native select.
  • sendKeys the option text into the select. Fragile and browser-dependent; the Select helper exists for this.
  • Selenium cannot interact with dropdowns. It has a dedicated helper for exactly this.

Now prove it in code

Knowing the answer and writing the test are different skills. These problems run your test against a working app, then against a copy with the behaviour broken on purpose, and tell you which behaviour your test missed.

More Selenium interview questions

Other frameworks