All jobs / Automation developer
Automation Fundamentals interview questions
Automation Fundamentals questions a Automation developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
Where should most automated checks live?
The strongest answer: In fast, isolated tests — units and API contracts — with a thin UI smoke on the money path, not a mountain of browser clicks for every field
Why it works: Exactly. Cheap layers catch cheap bugs. The UI pack is a scarce budget.
- Many cheap tests, few browser tests.
- UI pack = money path.
- Do not skip the glue.
- Tools follow the pyramid, not the reverse.
You need to prove a discount rule. Where do you put the first automated check?
The strongest answer: On the API or the pricing function — same inputs, same outputs — and keep one UI case for the badge the shopper sees
Why it works: Exactly. The rule is data in, price out. The UI is one witness, not the only one.
- Test the rule where it lives.
- One UI witness for the shopper.
- Do not wait on a visual licence.
- Spreadsheets are not CI.
Test B fails when you run it after test A, and passes alone. What is wrong?
The strongest answer: Shared leftover state — a cookie, a row, a cart — tests must set up and leave the world as they found it, or use data only they own
Why it works: Exactly. Isolation is the job. Order dependence is a bug in the suite.
- Own your data and session.
- Order dependence is a defect.
- Do not freeze run order.
- Do not merge tests to hide coupling.
A junior’s test is 80 lines of clicks with one expect at the end. What do you ask for?
The strongest answer: A readable arrange / act / assert — set the world, do one thing, check one outcome — so a failure names the story
Why it works: Exactly. Structure is how a red test teaches. A novel of clicks does not.
- Arrange, act, assert.
- One story per test.
- A failure should name the miss.
- Do not hide in a folder label.
A test only checks that the page did not throw. What is missing?
The strongest answer: An oracle — the price, the status, the email, the row — something a human would call “it worked”
Why it works: Exactly. Green without an oracle is a smoke that never looked.
- Name the outcome you prove.
- Timeouts are not oracles.
- More browsers ≠ more proof.
- Screenshots support; they do not replace.
A UI test fails one in four CI runs. What is it?
The strongest answer: A defect in the test, the waits, or the product — I isolate it and I do not hide it behind retries until green
Why it works: Exactly. A flake is unpaid work. Quarantine with an owner if you must; do not retry your way honest.
- Treat flakes as defects.
- Quarantine with an owner.
- Do not retry to green.
- Do not delete the only signal.
A PR adds a test that Playwright can click a native checkbox. What do you say?
The strongest answer: We are not here to certify the browser — test our wiring and our labels, not that Chromium can click
Why it works: Exactly. Trust the platform. Spend budget on our product.
- Do not certify the browser.
- Test our wiring and copy.
- Cross-browser is for our risk, not checkboxes.
- The tool is not the product.
A test logs in, updates the profile, buys, refunds, and checks the invoice PDF. What do you do?
The strongest answer: Split it — one reason to fail per test — and share setup helpers so you do not paste the login five times
Why it works: Exactly. A saga hides which step died. Helpers share setup; they do not merge stories.
- One reason to fail.
- Share helpers, not mega-tests.
- Retries are not a split.
- Do not exile the saga; cut it.
A new date-parsing helper is wrong on leap days. Where does the first test go?
The strongest answer: A unit test with a table of dates — I do not open a browser to prove a calendar
Why it works: Exactly. Logic belongs in a fast table. The picker gets one wiring check later.
- Logic → unit table.
- UI gets a wiring check.
- Do not screenshot arithmetic.
- Do not wait for a customer.
How do you debug a flake that only happens in CI?
The strongest answer: Reproduce with the trace, clock, and seed: wait, shared data, time, and parallelism — I do not add sleep and close the ticket
Why it works: Exactly. Flakes have causes: time, data, waits, isolation. Traces exist so you stop guessing.
- Use the trace and the seed.
- Check waits, data, time, parallel.
- Do not timeout your way out.
- Do not outsource the cause.
The framework offers retries: 2 on every test. When do you use it?
The strongest answer: Almost never on the whole pack — maybe a known third-party seam with a ticket — retries as default policy train you to ignore races
Why it works: Exactly. A retry is a confession. Default retries make flakes look like weather.
- No pack-wide retries.
- A retry needs a ticket.
- Find the race.
- Do not special-case the VP suite.
You quarantine a flake. What else is required?
The strongest answer: An owner, a ticket, a date, and a visible list — quarantine without a clock becomes a junk drawer of skipped truth
Why it works: Exactly. Quarantine is a waiting room with a name on the door.
- Owner + ticket + date.
- Keep the list visible.
- Folders are not SLAs.
- Do not retry it back to “fixed.”
When do you stub the payment API in a UI test?
The strongest answer: When you are proving the shopper path, not the acquirer — keep a separate sandbox test that really charges a test card
Why it works: Exactly. Stubs are honest when they name what they skip. You still owe a real-money sandbox somewhere.
- Stub the shopper path on purpose.
- Keep a real sandbox somewhere.
- Name what the stub skips.
- Do not stub production.
The UI pack is 70% of runtime and finds 10% of bugs. What do you do?
The strongest answer: Move cases down — API, contract, unit — and keep UI for journeys a lower layer cannot see; I do not ask for twice the runners first
Why it works: Exactly. Runtime vs bugs is the rebalance trigger. Hardware is the last lever.
- Move cases down the pyramid.
- Keep UI for true journeys.
- Runners last.
- Do not fashion-ban layers.
How do you talk about flakes with a director?
The strongest answer: As a budget — a visible rate, a quarantine SLA, and the merge-delay they buy — not “CI is moody”
Why it works: Exactly. Flakes are a tax you can name in time and trust. Mood is not a metric.
- Name the rate and the delay.
- Give a quarantine SLA.
- Do not joke it away.
- Own the causes you control.
People rerun the PR pipeline “until green.” What do you change?
The strongest answer: Make reruns visible and expensive in the conversation — quarantine the noisy tests, fix isolation — I do not add a “rerun” button and call it a platform
Why it works: Exactly. Rerun culture is a flake tax. Visibility plus quarantine beats a friendlier button.
- Show the rerun tax.
- Quarantine the noisy ones.
- Fix isolation.
- Do not mute the signal.
What is a fair quarantine SLA for a money-path flake?
The strongest answer: Days, with an owner, not “someday” — a money-path flake is a defect with a clock, or you do not have a money-path pack
Why it works: Exactly. The path you claim to protect cannot sit in a drawer.
- Short clock on money-path flakes.
- Named owner.
- Retries ≠ done.
- No drawer-until-reorg.
What does a good flake RCA fit on?
The strongest answer: One page: signal (wait/data/time/parallel), the fix, and the test that now proves it — not a 20-page timeline of every rerun
Why it works: Exactly. Cause class, fix, proof. Novels and blame are how people stop writing RCAs.
- Name the cause class.
- Name the fix and the proof.
- No blame map.
- No helper sleeps as RCA.
A “common” UI pack has no squad name on it. What happens next?
The strongest answer: You assign an owner or you split it back — unowned packs are where flakes go to live
Why it works: Exactly. A pack without a name is a junk drawer. Own or split.
- Name an owner or split.
- Folders are not owners.
- Do not grow an orphan pack.
- Do not surprise-delete the path.
You are asked for a two-year automation strategy. What are the first three pages?
The strongest answer: The risks you owe, the paved road (data, waits, CI trains), and the gates — not a tool bake-off and not a headcount chart without outcomes
Why it works: Exactly. Risks, road, gates. Tools and reporting lines are appendices.
- Name the risks you owe.
- Describe the paved road.
- Write the gates.
- Put tools in the back.
How do you defend a thin UI pack to a board that wants “what users see”?
The strongest answer: Users see outcomes; most bugs are cheaper in API and unit — I show late bugs we moved down and the minutes we gave back, not a lecture about ice-cream cones
Why it works: Exactly. Show converted bugs and time returned. Contempt and hiding lose the room.
- Show bugs moved down.
- Show minutes returned.
- Keep a thin honest UI pack.
- Do not insult or hide.
Rerunning red PRs is how the company ships. What do you change first?
The strongest answer: Make the tax visible, freeze new UI tests that do not meet the wait/data bar, and staff a flake week with owners — culture moves when the cost is on a page
Why it works: Exactly. Visibility, a bar, and named work. Speeches and new toys do not retire a habit.
- Put the tax on a page.
- Hold a bar for new tests.
- Staff named flake work.
- Do not tool-swap the culture.
Two directors each want their pet runner as the standard. How do you close it?
The strongest answer: A written decision: jobs, migration cost, and one paved road — losers get a sunset date, not a dual forever
Why it works: Exactly. One road, a sunset, a paper trail. Dual-forever is how flakes double.
- Write the decision.
- One paved road.
- Sunset the other.
- Do not dual-forever.
How do you make flakes a company problem, not a tester hobby?
The strongest answer: Put flake rate next to deploy frequency in the same review — owners, not heroes — so a noisy pack delays the people who cause it
Why it works: Exactly. Same room as delivery. Shame and hidden KPIs keep it a hobby.
- Review flakes with delivery.
- Owners, not heroes.
- No shame slides.
- Do not bounty-skip.
How do you keep exploratory testing alive when automation is mature?
The strongest answer: Humans hold new risk and living oracles; automation holds known repeats — I fund both, I do not declare exploration obsolete
Why it works: Exactly. A portfolio. Machines do the known; people do the new. Starving exploration is how escapes return.
- Fund exploration as a practice.
- Machines: known repeats.
- Do not double-run the suite.
- Do not make it a Friday leftover.