Automation Engineer interview questions

I separate test intent from transport details and keep shared infrastructure small.

• Test files describe business behavior, while browser pages, API clients, and infrastructure adapters own tool-specific calls.
• Fixtures compose capabilities such as authenticatedUser or seededOrder instead of exposing a global bag of helpers.
• Dependency rules prevent page objects from calling API assertions and keep reporting behind stable interfaces.

I share stable mechanics, not product-specific business language.

• Runner integration, retry policy, logging, HTTP transport, and artifact collection can serve many suites with versioned contracts.
• Checkout selectors, order builders, and domain assertions stay with the product because they change with that product.
• I extract code only after a second real consumer appears, since premature sharing creates release coordination without proven reuse.

I choose the narrowest scope that preserves isolation without making setup dominate runtime.

• A browser context and mutable user are test-scoped because cookies or changed data can leak between tests.
• A read-only service client or immutable reference dataset can be worker-scoped when concurrent access is safe.
• An expensive database container may be session-scoped, but each test still gets a transaction, schema, or unique tenant boundary.

I keep the fixture graph explicit and make every resource own its teardown.

• An order fixture requests apiClient and user directly instead of reading hidden global state.
• Cleanup is registered immediately after creation and uses a finally path so a failed assertion does not leave data behind.
• Teardown errors are reported separately from the test failure, preserving the original cause and the leaked resource identifier.

I use page objects for page-level workflows and component objects for reusable UI units.

• LoginPage can own navigation and sign-in, while DatePicker or DataGrid owns locators and actions repeated across pages.
• Assertions about business outcomes stay in the test, but a component may expose state such as selectedRows or errorText.
• Splitting every div into an object adds indirection, so I extract only units with behavior or meaningful reuse.

I choose Screenplay when many actor types combine the same capabilities across long workflows.

• Tasks such as PlaceOrder compose smaller interactions, while abilities such as BrowseTheWeb or CallAnApi make dependencies explicit.
• It reduces duplicated flows across buyer, support, and admin actors better than inheritance-heavy page objects.
• For a small CRUD application it adds vocabulary and call layers, so straightforward page and component objects remain cheaper.

I inject explicit interfaces at fixture or constructor boundaries instead of constructing dependencies inside helpers.

• An OrdersClient receives an HTTP transport, credentials provider, and logger, which lets unit tests replace each with a deterministic fake.
• The composition root chooses real Playwright or requests implementations once per test environment.
• I avoid a service locator because hidden runtime lookups make dependencies and fixture lifetimes difficult to trace.

I define and document one precedence chain, with command-line overrides above environment variables and checked-in defaults last.

• Non-secret defaults such as timeout and browser live in a typed config file, while tokens arrive only through environment variables or a secret manager.
• The loader records resolved non-secret values and their source so a CI mismatch can be reproduced.
• Unknown keys and conflicting options fail at startup instead of silently falling back during a test.

I fail fast on missing capabilities instead of discovering them halfway through the suite.

• A typed schema validates URLs, durations, enum values, and required credential references without printing secret values.
• A preflight checks service health, expected API version, database migration level, and required browser binaries.
• Optional suites declare feature flags or tags explicitly, so an unavailable dependency causes a clear skip or setup failure rather than misleading test failures.

The report should preserve enough context to identify the failed step without rerunning blindly.

• I attach the assertion diff, structured test steps, request and response metadata, browser trace, screenshot, and video only when useful.
• Build SHA, environment, browser, seed, shard, retry number, and test owner make the result reproducible and routable.
• Secrets, authorization headers, and personal data are redacted before artifacts are uploaded, with retention limited by policy.

I expose a small, versioned lifecycle API and isolate plugin failures from test execution where possible.

• Hooks such as beforeRun, afterTest, and onArtifact receive immutable event data instead of internal runner objects.
• Plugin order, timeout, and failure behavior are deterministic, with reporting plugins allowed to degrade without changing a passed test.
• Contract tests run third-party plugins against the next framework version before a breaking release.

I keep retry policy in the runner layer and never hide retries inside page actions or API clients.

• A retry reruns the whole isolated test with a fresh context and records every attempt, preserving the first failure evidence.
• Only known transient categories get a small retry budget, while assertion failures do not receive automatic polling beyond the assertion timeout.
• A test that passes on retry remains flaky in metrics and can be quarantined with an owner and expiry date, not counted as clean.

A fresh context gives strong session isolation at much lower cost than a new browser process.

• Cookies, local storage, permissions, and service workers are separated while the worker can reuse one browser process.
• Each test closes its context in teardown, which also closes pages and prevents state from reaching the next test.
• I launch a separate browser only for process-level settings, crash isolation, or extension behavior that contexts cannot separate.

I reuse the login setup, not a mutable account across concurrent tests.

• A setup project creates storageState for a worker-specific or role-specific user, and dependent projects load the correct file.
• Tests that change profile, cart, or permissions receive unique accounts or tenants even if initial cookies come from a template.
• Storage files stay out of source control and artifacts because they may contain reusable session cookies.

I intercept only the dependency whose behavior the scenario must control and leave the main system path real.

• A route can return a deterministic payment-provider decline while the application UI and backend still process the response normally.
• I assert the outbound method, body, and headers before fulfilling, so a broken integration request cannot pass against an overly permissive stub.
• Separate integration or contract tests verify the real provider boundary because interception cannot prove network compatibility.

I wait on user-visible or protocol-level conditions that represent readiness.

• Playwright locators auto-wait for actionable elements, and assertions such as toBeVisible poll until their own bounded timeout.
• For background work I wait for a specific response, URL, download, or application state, registering the waiter before the triggering action.
• networkidle is a discouraged readiness heuristic because continuous polling or recurring requests may prevent it from settling. If legacy code requires it, I give it a bounded timeout, but prefer assertions on a specific response or application state.

I isolate every mutable namespace before treating worker count as a speed setting.

• Users, email addresses, order IDs, files, and tenant names include the worker index or a generated run ID.
• Tests do not depend on order, shared downloads, or a common database row, and cleanup deletes only resources created by that test.
• External systems with strict limits use a semaphore or a serial project rather than allowing eight workers to corrupt shared state.

I base the matrix on user risk and browser-engine differences rather than running every test everywhere.

• A small critical-path suite runs on all three engines for each pull request, covering login, checkout, and core navigation.
• The broader regression can run on Chromium per commit and on Firefox and WebKit nightly, with production browser share reviewed regularly.
• Engine-specific skips require a linked product limitation and expiry, while shared tests use standards-based selectors and assertions.

I make rendering deterministic before adjusting screenshot tolerance.

• Baselines are captured in the same pinned browser and container image used by CI, with fixed viewport, fonts, locale, color scheme, and device scale factor.
• Animations, clocks, random data, and dynamic ads are disabled or masked, but real layout regions remain visible.
• Pixel thresholds cover minor antialiasing only; larger approved changes receive reviewed baseline updates rather than broad tolerance increases.

Automation catches repeatable rule violations but cannot certify that the experience is accessible.

• axe-core can detect missing names, invalid ARIA, contrast failures, and structural issues against rules integrated into component and page tests.
• Keyboard order, focus visibility, screen-reader announcements, zoom behavior, and task comprehension need manual checks with real assistive technology.
• I fail CI on new high-confidence violations and track known exceptions with rule, selector, owner, and expiry.