18 Selenium Python and pytest Interview Scenarios for Senior QA Engineers

Senior Python automation answers should sound like Python and pytest, not Java architecture translated into snake case. The important choices are fixture scope, generator teardown, process-level parallelism, exception boundaries, and small typed domain values. A global driver plus a broad conftest.py is convenient only until the first concurrent failure.

These interview scenarios follow one test from collection to finalization. For each answer, identify who creates the browser, what data the worker owns, how a wait produces evidence, and how pytest reports a failure if setup or teardown breaks.

Follow the pytest Resource Path

Selenium's Python API reference documents the binding surface. The project's state-isolation guidance specifically notes that pytest can yield a fresh driver from a fixture so it is quit whether the test passes or fails.

The fixture graph is executable ownership documentation. A broader fixture cannot safely depend on a shorter-lived resource, and hidden autouse behavior still runs whether the test signature explains it or not.

Fixture Lifecycle Scenarios

1. Why is a function-scoped driver fixture the safest default?

Each invocation receives a new WebDriver session and browser profile, so cookies, windows, storage, and navigation cannot leak from an earlier test. Function scope also makes retries and xdist workers easier to reason about. Startup cost should be measured and addressed with Grid capacity or faster data setup, not by silently sharing mutable browser state across unrelated cases.

2. How would you write teardown so driver construction failure does not raise another error?

Initialize the local reference to None, construct inside try, yield only after success, and quit conditionally in finally. Better still, keep construction in a small helper that cleans partial resources internally. The finalizer should never assume driver exists. A secondary UnboundLocalError or quit exception can obscure the actual missing browser or new-session failure.

@pytest.fixture
def driver(settings):
    browser = None
    try:
        browser = build_driver(settings)
        yield browser
    finally:
        if browser is not None:
            browser.quit()

3. Why should an autouse login fixture be challenged in review?

It makes every test navigate and authenticate, including tests for public pages or login itself. Dependencies become invisible and setup failures appear in places that did not request an account. I would expose an authenticated_page or domain fixture explicitly. Autouse remains useful for cheap universal policy, such as attaching sanitized test identity, but not for expensive mutable state by default.

xdist and Isolation Scenarios

4. How would you allocate accounts when pytest-xdist runs several workers?

Use the worker identity plus a run identifier to lease a unique account or namespace from an external coordinator. A module-level list is copied into each process and cannot prevent two workers choosing the same entry. The lease operation must be atomic, and release must tolerate a crashed or already-expired lease. Include the account alias, never its secret, in reports.

5. Why can a session-scoped fixture still be created multiple times in one CI run?

Session scope applies to one pytest process. xdist workers are separate processes, and CI shards or reruns create additional sessions. Therefore a session fixture is not a global singleton across the pipeline. External resource names must include run and worker dimensions, and setup must be repeatable. Exactly-once provisioning requires an external system with that contract, not a pytest scope label.

6. How would you prevent parallel artifact files from overwriting one another?

Build paths from a sanitized node id, worker id, invocation parameter, and attempt identifier, then create directories safely. Do not use only screenshot.png or a timestamp with coarse resolution. Each worker writes its own files, and the report merger receives explicit paths. Sensitive URLs, cookies, and user-entered values should be reviewed before page source or logs are persisted.

Python Wait and Element Scenarios

7. Why should a custom wait return an object instead of only True?

WebDriverWait.until can return a non-false value, so a condition can provide the exact element or immutable domain snapshot that satisfied readiness. The test then avoids another lookup against a changing DOM. I would return False while the transition is incomplete and let unexpected selector or protocol errors escape. Catching every exception turns real defects into vague timeouts.

8. How would you diagnose a stale element inside a page method?

Identify whether the method retained a WebElement across a render. Store locators or component roots with a defined lifetime, then find the element near the interaction. For an expected re-render, wait for the old reference to become stale and locate the replacement. Repeating the click in a broad exception loop can submit twice and hides the product transition the method should model.

9. Why is a lambda wait that returns an empty string easy to misread?

Python treats an empty string as false, so a legitimate observed value can keep polling even when the element is ready. A condition should distinguish "not ready" from valid domain data and document its return type. For text that may be empty, return a dataclass containing readiness and text, or wait on a separate state signal. Truthiness is part of the binding contract.

Page Models and Typed Contracts

10. How would you keep a page object from becoming a bag of locators and assertions?

Group behavior by page or reusable component, keep locators private, and expose user-intent methods returning typed results or the next page. Business assertions stay in tests or focused assertion helpers. The object may enforce its loaded invariant. If one class spans account, catalog, cart, and checkout, split by component and workflow boundaries rather than by arbitrary file size.

11. Why use dataclasses for configuration and captured evidence?

A frozen dataclass gives named fields, useful representation, and a stable type-checking surface for values such as browser target, Grid URL, and order receipt. Validate raw environment strings before constructing it. Do not put mutable driver objects or secrets into printable dataclasses. The benefit is an explicit value contract, not ceremonial type annotation around unvalidated dictionaries.

12. How would you expose fixtures without letting every test import from conftest modules?

Tests should request fixtures by name and import domain types or helper functions from normal packages. Keep plugin registration and shared fixtures in a deliberate support module when the suite grows. Directly importing fixture functions bypasses pytest's dependency and lifecycle behavior. A fixture is a resource declaration managed by pytest, not a utility function to call manually.

Outcome and Diagnostic Scenarios

13. How should a fixture know whether the test failed before taking a screenshot?

Use a pytest reporting hook to attach the call-phase result to the test item, then let an outcome-aware fixture or hook capture evidence while the driver remains available. Preserve setup, call, and teardown phases separately. A screenshot for setup failure may not have a valid browser, while a teardown failure should not relabel a passing call as an application defect.

14. Why should artifact capture use several guarded operations?

The page may be gone, the session may be disconnected, or one log type may be unsupported. Capture URL, screenshot, browser logs, and session metadata independently so one exception does not cancel the others. Report artifact failures as notes attached to the primary outcome. A single broad try around all evidence often leaves the team with nothing from the most difficult failures.

15. How would you handle quit() failing in a fixture finalizer?

Retain the original test outcome, record the session id and sanitized exception, and allow pytest to report the teardown problem. Do not suppress every quit error, because repeated failures indicate leaks or infrastructure loss. Also do not replace the call failure with a custom generic exception. Process cleanup beyond the client should be owned by Grid or the local service layer.

Remote Configuration Scenarios

16. Why should browser selection be parametrized at collection rather than changed inside the test body?

Collection-time parameters give each invocation a distinct id, fixtures can build the correct options before setup, and reports show which target failed. An if browser == ... branch inside the scenario mixes infrastructure with behavior and can produce misleading skips. Keep the requested and negotiated browser identities in metadata so a remote provider mismatch is visible.

17. How would you pass provider-specific capabilities without polluting every test?

Map validated semantic settings into standard options plus one provider adapter at the session boundary. Namespaced vendor values belong there, with credentials supplied through secure transport rather than printed capabilities. Tests request needs such as a platform or video artifact, not raw provider dictionaries. A local adapter can ignore unsupported optional features or reject mandatory ones clearly.

18. Why should a Python framework distinguish a remote command timeout from an explicit wait timeout?

An explicit wait means the session responded but the polled product condition never became ready. A remote command timeout can mean the HTTP transport, Grid, driver, or browser stopped responding during one command. They require different evidence and retry policy. Wrap errors with operation and session context while preserving the original exception type and traceback for diagnosis.

pytest Framework Checklist

• Default WebDriver to function scope and yield it from one clear owner.
• Treat xdist workers as separate processes that still share external systems.
• Use typed configuration values after validating raw environment input.
• Keep custom waits narrow, truthiness-aware, and evidence-returning.
• Capture outcome artifacts before finalization with unique worker-safe paths.
• Preserve original tracebacks and report teardown failures separately.
• Keep provider payloads and browser construction out of scenario code.

Conclusion: Make the Fixture Graph Tell the Truth

In a strong Python framework, the test signature reveals what the scenario consumes, pytest controls the resource graph, and each yield fixture releases exactly what it created. Parallel workers receive distinct external data, waits return meaningful evidence, and reports preserve Python tracebacks alongside browser diagnostics. That lifecycle clarity is the senior answer; compact syntax is merely a bonus.