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. Middle: deeper understanding, optimization, and real-world situations.
1
What belongs at each layer of the test pyramid, and what happens when the shape inverts?
Answer
Unit tests cover logic and run in milliseconds, integration tests cover the seams between components, and end-to-end tests cover a handful of paths that must never break. When the shape inverts into an ice cream cone — mostly UI tests — the suite becomes slow, flaky and expensive to maintain, and the team starts ignoring red builds. The pyramid is a statement about feedback speed, not about coverage percentage.
2
How does the client library talk to the browser?
Answer
Selenium sends HTTP requests to a driver process, which translates them into the browser's own automation protocol — one round trip per command, which is why chatty tests are slow. Playwright keeps a single WebSocket connection and speaks the DevTools protocol directly, which is why it can wait automatically and intercept network traffic. That architectural difference explains most of the practical ones.
3
How do you run tests in parallel without them interfering?
Answer
Each test needs its own data and its own browser context. Shared fixtures created once for the suite are the usual culprit — two tests mutate the same user and fail only when timing lines up. The fix is creating data per test with a unique key and cleaning it up after, and using a fresh context per worker so cookies and storage do not leak between them.
4
A test passes locally and fails in CI. Name the likely causes in order.
Answer
Timing first — CI is slower, so a race you never saw locally becomes visible. Then environment: different browser version, missing font changing layout, a different time zone. Then data: a leftover record locally that CI does not have, or the reverse. Then parallelism, if CI runs what you ran serially. Checking in that order finds it far faster than reading the diff.
5
What do you mock in an automated test, and what do you not?
Answer
Mock third-party services you do not control, especially paid ones, and anything nondeterministic — time, randomness. Do not mock your own backend in an end-to-end test, because then you are testing the front end against a fiction. Network interception is the useful middle ground: let the real system run, and stub only the one call you need to fail on demand.
6
How does a HashMap find a value, and why does hashCode matter?
Answer
It hashes the key to choose a bucket, then compares with equals inside that bucket. If hashCode is poor or constant, everything lands in one bucket and lookup degrades from constant time to a linear scan of a list. This is why overriding equals without overriding hashCode is a bug: two objects that are equal will hash differently and disappear from the map you just put them in.
7
What is a contract test and what does it catch that end-to-end tests do not?
Answer
It verifies that a producer and a consumer agree on the shape of a message, independently of running both at once. It catches the change nobody announced — a field renamed, a type widened, an optional made required — at the moment it is introduced rather than in the nightly run. Its value grows with the number of services, which is also why a single monolith rarely needs it.
🦎
Reading answers is not enough
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Middle QA Automation interview →Free · 3 interviews per month