QA Automation Engineer interview questions and answers

10 of 10 questions shown

1. juniorStabilityWhat makes UI tests flaky, and how do you fix the three most common causes?

   Model answer. Timing: fixed sleeps race the DOM, so use auto-waiting actions and retrying assertions. Shared or dirty data: create data per test through an API and avoid shared accounts. Order dependence: make each test independent and run them in random order. Quarantine a flaky test with a ticket and fix the root cause instead of adding blind retries.

   Tools: Playwright, Selenium

   I can answer this
2. juniorLocatorsWhich locator strategy do you prefer and why?

   Model answer. User-facing locators first: role and accessible name, label text, or a dedicated test id attribute. They survive refactors and double as an accessibility check. Avoid long CSS or XPath chains, positional selectors and generated class names, which break when layout changes.

   Tools: Playwright, Cypress

   I can answer this
3. midArchitectureExplain the Page Object Model and where it breaks down.

   Model answer. A page object wraps a page's locators and actions so tests read as intent and a selector changes in one place. It breaks down when objects become giant, hide assertions, or duplicate shared widgets. Prefer small component objects, keep assertions in the tests, and compose helpers instead of inheriting from a base page.

   Tools: Selenium, Playwright

   I can answer this
4. midWaitingHow does Playwright auto-waiting differ from Selenium explicit waits?

   Model answer. Playwright actions wait for the element to be attached, visible, stable, enabled and able to receive events, and expect assertions retry until a timeout. Selenium does not check actionability for you, so you wait with WebDriverWait conditions. Mixing Selenium implicit and explicit waits gives unpredictable timeouts, so use explicit waits only.

   Tools: Playwright, Selenium

   I can answer this
5. midTest dataHow do you set up data so tests can run in parallel without clashing?

   Model answer. Each test creates its own records through an API or database fixture with unique identifiers and removes them, or runs in a disposable tenant. Read-only reference data can be shared. Never let two tests mutate the same user account or order.

   I can answer this
6. midCIA suite passes locally but fails about one run in ten on CI. Walk through your diagnosis.

   Model answer. Capture traces, video and logs on failure and look at what differs: CPU limits that slow rendering, viewport and locale, parallelism and shared data, and network calls to real services. Reproduce by repeating the test many times inside the same container. Fix the cause, then track flake rate per test so regressions are visible.

   Tools: GitHub Actions, Docker

   I can answer this
7. midSpeedWhy use API calls to prepare state in UI tests?

   Model answer. Logging in and building state through the UI is slow and fails for reasons unrelated to the behaviour under test. Create data through the API and reuse a stored authenticated session, then exercise only the UI flow you care about. The test gets faster and failures point at the feature.

   Tools: Playwright, Cypress, Postman

   I can answer this
8. seniorStrategyHow do you shape the test pyramid for a microservices web app and what should the UI layer own?

   Model answer. Many unit tests, consumer-driven contract tests between services, API and integration tests per service, and a thin UI layer. UI tests own a few critical journeys and cross-service wiring such as sign-up or checkout, not field validation or business rules, which are cheaper to test lower down.

   I can answer this
9. seniorSpeedYour suite takes 70 minutes. How do you get it under 15?

   Model answer. Measure first: slowest tests and setup cost. Shard across machines, run workers in parallel, replace UI setup with API calls and reuse authenticated state. Remove duplicated coverage, run only impacted tests on each pull request and the full suite nightly.

   Tools: GitHub Actions

   I can answer this
10. seniorTool choiceWhat are Cypress's architectural limits compared with Playwright and Selenium?

    Model answer. Cypress runs inside the browser next to the app, which gives time-travel debugging but constrains multiple tabs, cross-origin navigation (cy.origin helps) and browser coverage. Commands are queued, not async/await. Playwright and Selenium drive the browser from outside, so multi-tab and multi-context scenarios are straightforward.

    Tools: Cypress, Playwright, Selenium

    I can answer this

No question matches those filters. Clear the search or choose All.