QA Automation interviews test framework knowledge, automation patterns, and — most of all — whether you can write tests that stay green for reasons other than luck. Below are common questions with model answers.
Every question comes with a model answer you can compare yours against.
Page Object Model wraps each page or component in a class that exposes locators and high-level actions, so tests describe intent rather than clicks. The problem it solves is maintenance: when the UI changes, you update one page object instead of fifty tests. It also removes duplication and makes tests readable to people who did not write them.
An implicit wait is a global setting that makes every element lookup retry for up to N seconds. An explicit wait targets one specific condition — element clickable, text present — and only waits for that. A fluent wait is an explicit wait with a configurable polling interval and ignorable exceptions. Mixing implicit and explicit waits causes unpredictable cumulative timeouts, so most teams disable implicit waits entirely and use explicit ones.
Preferred order is a dedicated test attribute like data-testid, then id, then a stable CSS selector. XPath gets a bad reputation because absolute XPath breaks with any DOM change, and long relative XPaths are hard to read. XPath itself is fine and sometimes necessary — for example selecting by visible text or navigating to a parent — the problem is brittle XPath, not the language.
A flaky test passes and fails without any code change. The usual causes are timing assumptions (hard sleeps instead of waiting for a condition), shared mutable test data, test order dependency, animations, and unstable environments or third-party services. Fixes: wait for explicit conditions, generate isolated data per test, make tests independent and idempotent, stub external services, and quarantine flaky tests rather than rerunning until green.
Parallelism is configured at the runner level and usually combined with a Selenium Grid or containers. The problems are shared state: tests writing to the same user account or database rows, port and file collisions, and order-dependent assumptions. The fix is that each test creates its own data with unique identifiers, avoids global setup that mutates shared resources, and never assumes it runs alone.
Playwright talks to browsers over the DevTools protocol, auto-waits for elements to be actionable, and ships with tracing, network interception, and parallel isolation built in — so it needs far less wait plumbing. Selenium is a W3C standard with the widest browser, language, and grid support, and is entrenched in existing enterprise infrastructure. Pick Playwright for a new project focused on modern browsers; pick Selenium when you need broad legacy support or must fit an existing Selenium ecosystem.
You verify status codes, response schema, body values, headers, and error handling for invalid input, plus authentication and authorization boundaries. Tools are typically Postman or Insomnia for exploration and RestAssured, Playwright APIRequest, requests, or supertest for automated suites. API tests are cheaper and far more stable than UI tests, so most coverage should live there.
The pyramid says you should have many fast unit tests, fewer integration tests, and very few end-to-end tests, because cost and flakiness rise as you go up. A commonly cited split is roughly 70/20/10, but the number matters less than the principle: push each check to the lowest level that can catch the bug. E2E tests should cover critical user journeys only, not business logic.
Tests run on every pull request, usually split into a fast smoke suite on each commit and the full regression on merge or nightly. The pipeline provisions a clean environment, runs suites in parallel, publishes reports and artifacts such as screenshots and traces, and fails the build on regressions. The rule that makes it work is that a red pipeline blocks the merge — otherwise the suite decays.
Data-driven testing separates test logic from test data, so one test runs against many input sets from a CSV, JSON, or parameterized provider. It multiplies coverage without multiplying code and makes adding a new case a data change rather than a code change. The trap is generating unreadable failures — always include the input data in the test name so a failure tells you which case broke.
Automate stable, repetitive, high-value checks: regression suites, smoke tests, API contracts, and data-heavy scenarios. Do not automate rapidly changing UI, one-off checks, exploratory work, usability and visual judgement, or anything where writing and maintaining the test costs more than running it manually. The deciding question is how many times the check will run before it changes.
Each test should create the data it needs and clean up after itself, ideally through API calls or database seeding rather than the UI, because that is faster and less fragile. Shared fixture data leads to order dependency and mysterious failures. For environments, containers or ephemeral instances per pipeline run give isolation; when a shared environment is unavoidable, namespace all data with a unique run identifier.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a QA Automation interview →