Automation testing interview questions

The answer they want: smoke on the critical path — login, core transaction — because it runs on every single build and pays back immediately. Starting with edge cases or a fancy framework before smoke exists is effort in the wrong order.

100% of WHAT is the question. Full regression automation of stable flows, yes. But exploration, usability and fast-changing features resist scripting — chasing a percentage there produces brittle tests and worse coverage, not more quality.

Test around it: a test-mode bypass or fixed OTP in lower environments, mock the SMS/email provider and read the code from its API, and keep one manual check of the real flow per release. Never weaken production security for tests.

For layout stability on stable pages, yes — screenshot diffs catch broken CSS cheaply. For 'does this look good', no: tools compare pixels to a baseline, they can't judge design. Use them where the baseline itself rarely changes.

Maintenance is the big one — locator updates, flake hunts, framework upgrades eat 20-30% of automation time forever. Also infrastructure (grid/CI minutes) and the false-alarm tax: every flaky red build costs someone an investigation.

Maybe yes: a green suite that lets you release weekly with confidence is doing its job — it's insurance plus speed, not just a bug net. But audit it: if it also NEVER fails, check the assertions actually assert something.

The driver speaks Chrome's internal automation interfaces, which shift between versions — a mismatched pair fails at session start or, worse, misbehaves subtly. Selenium Manager now auto-downloads the matching driver, which killed a decade of setup pain.

One persistent WebSocket connection to the browser instead of an HTTP request per command — lower latency, and it enables auto-waiting and event listening. That architectural difference is most of why Playwright tests flake less.

Two moves: locate by the most stable semantics available — roles, labels, names — and ask the developers to add test ids, which is a one-line change per element. Teams add them happily once flaky-locator cost is visible.

Copy changes without anyone telling QA — 'Sign in' becomes 'Log in' in a Tuesday tweak and the suite goes red. Fine for genuinely stable text, dangerous for anything marketing can edit.

Measurably, marginally — irrelevant next to network and wait time in a real suite. Choose on readability and capability, not micro-performance; anyone citing speed as the main reason is repeating a 2012 blog post.

CSS handles it: .tab.active button.submit — downward and class-based. If 'active' were only detectable from a child's text, that's when XPath enters. Explaining the boundary is the actual answer.

It guarantees uniqueness without understanding your app's semantics — the tool can't know which attributes are stable. It's a starting hint, not a locator. Rewrite it against meaning before it enters the repo.

It scans the document rather than one path, but on real pages the difference is noise. Correctness and survival beat theoretical scan cost every time.

Ignore the id entirely: locate by role and accessible name (getByRole('textbox', {name: 'Email'})), by label association, or by a stable container plus position of meaning. The id is one attribute, not the element's identity.

Bring the bill: 'locator breakage cost us N red builds and X hours this month; data-testid is one line per element.' Engineers fix costs they can see. Offer the naming convention yourself so it's a paste, not a project.

Clickable before clicks, visible before reads, presence for existence checks, text/attribute values for state changes, and invisibility of spinners before proceeding. Waiting for the WRONG condition — presence when you need clickable — is its own flake source.

Every action auto-waits for actionability — attached, visible, stable, enabled — so 90% of explicit waits disappear. You still wait explicitly for app-level states: data loaded, spinner gone, URL changed.

Rarely and honestly: debugging locally, pacing against a rate-limited external system, or a genuinely time-based feature like a countdown. In committed test code, each one deserves a comment explaining why a condition couldn't express it.

That it treats the symptom and slows every future run. Each flake has a real condition being raced — find it, wait for it. Offer to pair on one: converting a sleep to a condition usually takes minutes and teaches the pattern.

Its Locator is a query, not a held node — page.locator() re-finds the element at every action. Selenium's findElement returns the node itself. That design difference is the whole bug class appearing or disappearing.

As a last resort it works, but it papers over the real issue: you acted before the re-render settled. Waiting for the update to complete, then re-finding, fixes the cause — retry hides the timing race.

Model components, not just pages: a NavBar, a SearchWidget, a data table used everywhere. Page classes then compose components. Matching the app's structure is the point; 'page' is historical naming.

A ten-test smoke pack against two screens doesn't need the ceremony — locate inline and stay simple. The pattern earns its structure when tests and pages multiply; introduce it when duplication starts, not on day one.

A guard that the page actually loaded (fail fast with a clear message) is defensible — it's a precondition, not a verification. Business assertions never: the test must show what it proves.

Neither — a third layer: clients/helpers/fixtures. Page objects mirror the UI; tests tell scenarios; setup infrastructure gets its own module. Three clean layers is the shape of a maintainable framework.

Honest, specific, current: 'more API-level checks — too much rides through the UI', or 'contract tests before the microservice split bit us', or 'test-data factories earlier; shared fixtures caused parallel collisions'. Zero regrets reads as zero experience.

The real maintainability metric: clone, one-command setup, a template test to copy, page objects discoverable by name, README with the golden path. If the answer is 'they shadow me for a week', the framework is a personal fiefdom, not infrastructure.

Recorded scripts anchor to whatever the recorder saw — brittle locators, hardcoded data, zero reuse — so they break in bulk at the first UI change. Fine for prototyping a flow; unmaintainable as a suite.

When non-programmers must author tests — some enterprise and outsourcing contexts. The cost is building and maintaining the keyword engine, which usually exceeds teaching people basic code. Rarely the right trade today.

Small, logic-coupled sets inline next to the test (reviewable in the same diff); large or shared matrices in files; anything environment-specific in fixtures/config. The wrong answer is one giant spreadsheet nobody versions with the code that reads it.

Data-driven runs YOUR chosen rows; property-based (Hypothesis, QuickCheck) generates inputs against an invariant and shrinks failures to minimal cases. Complementary: your boundaries plus its exploration.

True pipelines only — verify-payment genuinely needs create-order. It skips dependents on failure, which reads clean, but it also serialises tests and breaks independence; overuse turns a suite into one fragile chain.

@BeforeTest wraps a <test> block from the suite XML — once per block; @BeforeMethod runs before every single @Test. The XML meaning of 'test' confuses everyone once; knowing it marks you as having actually used TestNG.

function/class/module/session. Session-scoped things are shared state: one browser reused everywhere is fast until one test dirties it and poisons the rest. Share expensive immutable things; keep mutable state function-scoped.

Instead of BaseTest with setUp doing everything for everyone, each test requests exactly what it needs — a test needing only an API client doesn't pay for a browser. Composition, explicit dependencies, no fragile class hierarchy.

Timing: in the JUnit 4 era TestNG alone had data providers, groups and parallel out of the box — exactly what UI suites need. A decade of tutorials and templates followed. Inertia is a real technical force.

@ParameterizedTest with sources — @ValueSource, @CsvSource, @MethodSource. MethodSource is the closest match: a method returning a stream of arguments, each becoming a named run.

Every soft assertion evaluates, records its failure — and the test goes green. It's the quietest bug in test code, and it's why some teams wrap soft assertions in helpers or lint for a missing assertAll.

expect.soft() in Playwright — failures mark the test failed but execution continues; the report lists them all. Same idea, minus the assertAll footgun, since the runner tracks soft failures itself.

Myth as a law, wisdom as a smell: one BEHAVIOUR per test, which may take several assertions to pin down. Twelve assertions spanning three flows is three tests wearing one name.

Everyone has: asserting a variable equals itself, asserting inside a try that swallows, asserting on the input instead of the result. It's why 'can this fail?' belongs in test code review — a suite's value is its ability to go red.

Run it in a loop — 50 times, artifacts on: screenshots, video, trace. Failure pattern tells the story: fails only in parallel = shared state; only in CI = environment; at random points = timing. Evidence first, fix second.

Reproduce below the UI: hammer the same operation via API. If the double-charge appears with no browser involved, it's the product. The suite just did its job — that finding is a bug report, not a test fix.

Check coverage first: some cover critical paths and need fixing; some are redundant and CAN go — deletion with eyes open is a valid triage outcome. Blanket deletion silently drops protection you'll rediscover in production.

Make it cost something visible: each quarantined test has a ticket, an owner and an age; the count is on the team dashboard; a cap ('max 10, else we stop and fix') keeps pressure on. Invisible quarantine grows forever.

Around genuinely unreliable EXTERNALS you can't fix — a third-party sandbox with known hiccups — scoped to that boundary, not global. Global retry on all tests is an confession that red doesn't mean anything.

It's built in AND reported: retried tests are marked 'flaky' in the report, which is exactly the honest pattern — allowed, visible, impossible to ignore. Adopt the reporting half, not just the retry half.

Run it in random order (pytest-randomly, JUnit's Random order) and in parallel — the failures that appear are your dependency map. Fix them in failure-frequency order; each fix usually reveals the next.

Via UI, yes; via API or DB seeding, milliseconds. Speed-share immutable expensive things (one browser per worker); never share mutable state. Slow-but-honest beats fast-but-entangled — and API setup gives you both.

Separate concern: seeded/anonymised datasets in a dedicated environment for volume and migration testing. Functional tests keep creating their own small data; never point them at the shared big set 'because it's there'.

Same discipline as production: environment variables or a secrets manager, injected in CI — never in the repo. A test password in Git history is still a password in Git history.

Options in order: a test-only auth bypass in lower environments (issued by the backend, flag-gated), programmatic token minting against the IdP's API, or one real UI login per session cached and reused. Never script the third-party's login UI per test.

No — coverage moves to where it belongs: one dedicated login spec (plus lockout, errors, remember-me). Two hundred incidental logins were never coverage; they were repetition wearing coverage's clothes.

Less than folklore says: rendering/CSS edge cases, date/file inputs, clipboard and permissions APIs, Safari's stricter storage and autoplay policies. Business logic almost never — which is why the scoped matrix is rational, not lazy.

Named configurations in playwright.config — chromium/firefox/webkit, or 'mobile Safari' with a device profile, or even 'logged-in vs guest'. One test base, N projects, parallel by default: the matrix without shell scripting.

Grid: you own infra — free-ish but you patch, scale and debug it. Cloud: per-minute cost, zero maintenance, real device farms, video/logs included. Small teams almost always net cheaper on cloud once engineer-hours are priced in.

One jar with roles (router, distributor, node), native Docker support, W3C-only protocol, better UI and observability. The old hub-jar/node-jar juggling and JSON Wire quirks are gone.

Architecture: persistent WebSocket instead of per-command HTTP, and every action auto-waits for actionability (visible, stable, enabled). The waits you used to hand-write are the protocol's default behaviour.

Only with a driver: flake pain or speed pain that waits can't fix, and then incrementally — new tests in Playwright, old suite frozen and shrinking. Big-bang rewrites of working suites are how teams spend a year standing still.

A JS/TS team testing a single-origin web app, valuing debugging experience and component testing — Cypress is delightful there. Tool fit is about your app's shape, not the tool's Twitter reputation.

Stub window.open to same-tab, assert the URL that would have opened, or test the second tab's content as its own visit. Workable — but if your product is genuinely multi-window, you're fighting the tool's model.

Readable reports don't need Gherkin: good test names plus reporters get you there without step-definition overhead. Adopt Cucumber only if non-engineers will collaborate on scenarios — that's the feature; everything else is costume.

Ultra-generic steps ('When I click "{string}"') turn Gherkin into a worse programming language; duplicated near-identical steps pile up regex conflicts. Healthy suites keep steps business-level and few.

Because they aren't <select> elements — they're styled divs/ULs. Select drives the native element's API. For custom ones you automate the interaction: open, wait for options, click. Inspect the tag first; it decides the approach.

Mostly dissolves them: frameLocator() pierces iframes inline, new pages arrive as context events you await, dialogs via page.on('dialog'). The switching ceremony is largely Selenium-specific.

Existence is the weakest check. Real assertions: size non-zero, correct type, and content — parse the CSV/PDF and verify rows or totals match the data on screen. 'A file appeared' has passed while exporting garbage.

Oversized file, zero-byte, wrong extension, renamed type (exe as jpg — does the server check content?), unicode filename, and double-submit of the same upload. The server-side checks are the security-relevant ones.

Always-on traces cost time and storage on green runs; on-first-retry captures only when something failed once — near-free and you still get the artifact. Default to on-first-retry in CI; full-on when hunting a specific ghost.

Per-failure artifacts inline, failure history (new vs known), duration trends, flaky markers, and the app build/commit under test. A count without artifacts is a scoreboard; engineers need a crime scene.

Environment drift: missing browser deps (use the official images), headless-vs-headed differences, viewport assumptions, and resource starvation making timing flakes bloom. Pin images and versions; 'works on my machine' has a CI edition.

The smoke/critical pack — yes, absolutely blocking. The full regression — usually gating releases, not every merge. The nuance: anything blocking must be trusted; one tolerated flake in the gate and the gate is theatre.

Rebase MY unpushed/branch-local work for a clean linear story; merge for anything shared. Golden rule: never rewrite history others have pulled. In squash-merge teams the distinction mostly dissolves at PR time anyway.

Recover first, lecture later: reflog (or the PR's old head) still has your commits — cherry-pick them back. Then fix the process: protected branches, no force-push to shared, --force-with-lease if force is ever needed.

The failure mode inverts: bad app code fails visibly; bad test code PASSES silently — a green liar. So review priority shifts to assertion strength and false-pass risks over style. A wrong test is worse than no test.

Pick the two that teach the most (assertion strength, independence), fix-forward the trivia, pair on the pattern. Fifteen comments teaches fear, not testing. The goal is their next PR, not this one's perfection.

What users actually experience: critical journeys end to end, the wiring between front and back, layout-breaking regressions, browser-specific input handling. If the check makes sense with the screen off, it belongs lower.

Per test, true — per suite, it buys that confidence at brutal cost: slow, flaky, blunt failures. The pyramid isn't ideology, it's economics: same coverage, faster signal. Keep E2E for what only E2E can see.

The element may be MID-disappearing — or your check runs before the action's effect renders, passing against the old DOM. The positive anchor ('save confirmed') pins the moment; only then does absence mean anything.

findElement throws (and burns the implicit wait) when missing; findElements returns an empty list instantly. For absence checks the list version is both faster and exception-free — a classic Selenium idiom.

It pins the found element — on any re-render you're holding a stale node, and the exception points nowhere near the cause. It optimises the cheap part (lookup) at the price of the expensive part (debugging).

No — consistency beats purity in a working suite. Keep the pattern, avoid @CacheLookup, and if the team ever migrates tooling, that's the natural moment to drop the proxies. Rewrites need better reasons than taste.

Then two birds: file the missing labels/roles as accessibility findings (they're real user-facing bugs) and locate by the best available meaning meanwhile. Automation pain and a11y debt are usually the same debt.

Cost, not principle: 'N red builds and X hours last month were locator breakage; data-testid ends that class of failure for one line per element — here's the naming convention ready to paste.' Engineers argue with opinions, not with bills.

Artifacts first — screenshot, video, trace tell most stories. Then diff the environments: viewport, fonts, locale, timezone, GPU flags. Reproduce locally WITH headless on and the same viewport before touching the test.

Old headless was a separate lean build with real behaviour gaps; new headless (—headless=new, now the default path) is the actual Chrome binary without UI — far fewer differences. If you last checked in 2021, the folklore is stale.

App build/commit, environment, browser+version, worker count, and data seed if randomised. Half of 'weird failures' are explained by 'wait, WHICH build was this?' — make that question impossible.

Report them distinctly: a fixture failure marks tests as errored/blocked, not failed — different colour, different meaning. Twenty 'failures' that are one dead environment should read as one incident, not twenty bugs.

Test interaction: shared state, data collision in parallel, or resource starvation slowing timings. Bisect: run the failing test with progressively larger neighbouring sets until the culprit pair emerges.

Viewport, timezone, locale, browser version (containers), dependency lockfiles, and seeded data. Every unpinned variable is a future 'works on my machine' with your name on it.

Build them from captured real responses, re-record on a schedule, and let the scheduled contract check against the sandbox catch shape changes — its failure means 'update mocks and code', which is exactly the alert you want.

Because that's where integrations actually die in production, and no happy-path test touches them. Your retry, fallback and user-facing error handling only exist if a test forces them to run — mocks make those cases one line.

Mask dynamic regions (dates, avatars, ads), pin fonts/viewport/animations off, compare perceptually rather than pixel-exact, and scope to components over full pages. The discipline is choosing WHAT to snapshot, not the tool.

Components (Storybook-style) are tighter: small diffs, obvious blame, cheap baselines. Full pages catch integration/layout collisions between components. Design systems get both — components broadly, a few key pages as canaries.

Selectors/test ids, auth mechanism (API login possible?), environments and data control, API docs, feature flags, existing tests, and who owns fixes. It predicts your velocity better than any tool choice.

The app is the documentation: explore with devtools open, read API traffic, check analytics for the real top journeys, and write down what you observe as testable statements. Your notes become the spec everyone corrects.

Evidence: never-failed-in-a-year tests covering unchanged code, duplicates of lower-layer checks, tests for removed features. Audit coverage before each cut. A suite where every test earns its runtime beats a bigger honest-looking one.

Everyone commits to standards, one rotating owner watches the dashboards and drives the burn-down. 'Everyone owns it' with no name attached is how three-hour nightlies happen — shared values need a single throat to choke, kindly.

Read artifacts (trace/screenshot) → reproduce the PRODUCT behaviour by hand or API → failing: file the bug with the trace attached; broken: fix the test now or quarantine with a ticket. Red never gets ignored and never gets auto-rerun into silence.

The silent passer — a broken test at least announces itself. A test that can't fail is negative value: it spends runtime manufacturing false confidence. It's why 'can this fail?' is a review question.

Everyone has the whole history locally — you can commit, branch and view history offline, and there's no single point of failure. You sync with the remote when you're ready, not for every operation.

On your own feature branch before opening a PR — replay onto latest main for a clean, linear history and to resolve conflicts once. Keep it to branches only you have.

Pull/rebase onto main frequently so your branch doesn't drift, keep changes small and focused, and coordinate when two people must touch the same file. Long-lived branches are conflict factories.

Interactive rebase to squash, reorder or reword them into a clean sequence — on your own branch only. Present a readable history for review, not the raw stream of 'wip' commits.

Before rebasing, or when you want to review incoming changes (git log origin/main) before they touch your branch — so an integration is a deliberate step, not an automatic one.