Selenium · Browser automation foundations
What are the most common Selenium mistakes?
Short answer
The recurring mistakes are fixed sleeps, brittle locators, shared drivers, missing cleanup, mixing implicit and explicit waits, and asserting before the UI settles. Each turns a test into a slow or unreliable signal.
Most Selenium pain is self-inflicted rather than a limitation of the tool. The same few anti-patterns appear in almost every unstable suite, and each has a concrete replacement.
Thread.sleep(5000);
driver.findElement(By.xpath("/html/body/div[3]/div[2]/button")).click();
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement button = wait.until(ExpectedConditions.elementToBeClickable(
By.cssSelector("[data-testid='save']")));
button.click();
wait.until(ExpectedConditions.textToBePresentInElementLocated(
By.cssSelector("[role='status']"), "Saved"));- Thread.sleep instead of waiting for an observable state
- Absolute XPath and generated class names instead of stable test ids
- A static driver shared across tests, causing state leakage and parallel races
- No quit or cleanup, leaving browser processes and sessions behind
- Implicit and explicit waits mixed, producing unpredictable delays
- Asserting immediately after an action before the UI has updated
- Catching exceptions and retrying inside the test instead of fixing the cause
- Testing every rule through the UI instead of using API or unit tests
The cost compounds. A five-second sleep in twenty tests adds over a minute to every run, and a brittle XPath breaks on a deployment unrelated to the feature. Cleanup failures eventually exhaust CI memory or Grid slots, which then looks like random infrastructure instability.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Which mistake causes the most flakiness?
- 2Why is a shared driver worse than a shared page object?
- 3How do you convince a team to remove sleeps?
- 4What would you fix first in an inherited suite?
Say it in the interview
The biggest offenders are fixed sleeps, brittle selectors, shared drivers and missing cleanup. I replace sleeps with explicit waits on the state the test depends on, move locators to stable test ids, and isolate the driver per test. I also stop asserting before the UI settles. Fixing these patterns usually improves stability more than changing frameworks.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Selenium mock interview and get scored feedback on depth, clarity and confidence.