Test Automation Interview Questions

Test automation interview questions#

Automation interviews test both concepts and code. Expect to write a small Selenium, Cypress or Playwright test on a whiteboard or shared screen.

1. Which tests should you automate first?#

Stable, frequently run, high-value tests: smoke tests, critical business flows, regression tests for serious past bugs and data-heavy checks. Not features still changing or one-off checks.

2. Explain the test automation pyramid.#

Many fast unit tests, fewer API/integration tests, and a small number of end-to-end UI tests. Most logic should be checked at the lowest level that can catch the bug, because UI tests are slower and more fragile.

3. What is the Page Object Model and why use it?#

A design pattern where each page's locators and actions live in one class. Tests call page methods instead of using selectors directly, so a UI change is fixed in one place and tests read like user steps.

4. Implicit vs explicit vs fluent waits in Selenium?#

Implicit waits apply globally to element lookups. Explicit waits (WebDriverWait + expected conditions) wait for a specific condition such as visibility or clickability. Fluent waits are explicit waits with a custom polling interval and ignored exceptions. Prefer explicit waits and never mix them with implicit waits.

5. Why should you avoid Thread.sleep / time.sleep?#

A fixed sleep is always too long when the app is fast and too short when it's slow. Waiting for a condition is both faster and more reliable.

6. Which locator strategy do you prefer?#

Unique IDs or dedicated data-test attributes, then name and CSS selectors. XPath only when nothing else works, and never absolute XPaths tied to page structure.

7. How do you handle a StaleElementReferenceException?#

The element was re-rendered after you found it. Locate it again right before using it, or wait for the condition that indicates the page finished updating. Page objects that store locators (not elements) avoid most cases.

8. What is data-driven testing?#

Running the same test logic with multiple sets of input data — e.g. pytest parametrize, TestNG @DataProvider, or CSV/JSON data files.

9. What is BDD?#

Behaviour-Driven Development: behaviour written as Given/When/Then scenarios in Gherkin, mapped to step definitions in code (Cucumber, pytest-bdd, SpecFlow). Valuable when business stakeholders read the scenarios.

10. What is a flaky test and how do you fix one?#

A test that passes and fails on the same code. Find the root cause — timing, shared data, order dependency, animations, external services, dates — and fix it with proper waits, isolated data and mocks. Retries are a temporary safety net, not a fix.

11. How do you run tests in parallel safely?#

Make tests independent: each creates its own data and doesn't rely on order or global state. Then use the runner's parallelism (pytest-xdist, TestNG parallel, Playwright workers, Selenium Grid).

12. How do you integrate automated tests with CI/CD?#

Run fast suites on every pull request and the full suite on merge or nightly, headless, with reports, screenshots and videos uploaded as artifacts. A failing test blocks the merge.

13. What is Selenium Grid?#

A way to run WebDriver tests on remote machines and multiple browsers in parallel through a hub that routes sessions to nodes. Cloud services (BrowserStack, Sauce Labs) provide the same at scale.

14. Selenium vs Cypress vs Playwright?#

Selenium: W3C standard, every language and browser, more setup. Cypress: JavaScript, runs in the browser, excellent debugging and automatic retries, limited multi-tab/origin support. Playwright: all browser engines, auto-waiting, parallel by default, built-in API testing and tracing; usually the best default for new projects.

15. How do you test something that depends on a third-party API?#

Mock or stub it in UI and integration tests for reliability (cy.intercept, Playwright page.route, WireMock), and keep a small number of contract or end-to-end tests against the real sandbox.

16. How would you handle test data?#

Create it per test through APIs or database fixtures, use unique values (timestamps, UUIDs), clean up after, and keep reference data in version-controlled files.

17. How do you measure the success of automation?#

Release confidence and speed: time from commit to feedback, defect leakage, regression time saved, flaky-test rate and how often the team trusts a red build. Not the raw number of test cases.

18. Write a test that logs in and verifies the dashboard.#

Use a page object: open the login page, call login(user, password), wait for the dashboard URL and assert a dashboard-only element (like the user's name) is visible. Mention waits, test data and cleanup — interviewers care about structure, not memorised syntax.