Senior QA Automation — QA automation interview questions

What is a flaky test? Name the causes and how to eliminate them.

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.

How do you run tests in parallel? What problems arise?

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.

How does Playwright differ from Selenium? When would you pick each?

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.

How do you test a REST API? What tools do you use?

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.

What is the test pyramid? What unit/integration/e2e ratio is optimal?

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.

How do you integrate automated tests into a CI/CD pipeline?

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.

What is data-driven testing and how do you implement it?

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.

What should you automate and what should you not?

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.

How do you handle test data and environment setup?

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.