Automation Testing and SDET Background Questions

Experience in test automation and software development for testing, including frameworks, languages, test strategies, types of testing performed, scale of test suites, and contributions to automation frameworks. Also includes software development engineer in test career paths, and examples of how automation improved quality or speed of delivery. Candidates should discuss tools, CI integration, and any ownership of regression or end to end test infrastructure.

EasyTechnical

43 practiced

Describe the purpose and use of fixtures in PyTest and the equivalent setup/teardown mechanisms in JUnit. Explain fixture scopes (function, class, module, session), give examples of expensive external resources to manage, and explain strategies for resource cleanup and leak prevention during parallel test execution.

Sample Answer

**Purpose (PyTest) and Equivalent (JUnit)**

PyTest fixtures provide reusable setup/teardown logic injected into tests via parameters; they improve readability, reduce duplication, and manage test dependencies. In JUnit, equivalent mechanisms are @Before/@After (per-test), @BeforeClass/@AfterClass (per-class) and JUnit 5’s @BeforeEach/@AfterEach, @BeforeAll/@AfterAll or extensions for richer lifecycle control.

**Fixture Scopes (PyTest)**

- function — runs before/after each test (JUnit: @BeforeEach/@AfterEach)- class — once per test class instance (use with @pytest.mark.usefixtures or class-level fixtures)- module — shared for all tests in a module (JUnit: @BeforeAll/@AfterAll in a test class representing module-level)- session — one time per test run, useful for expensive global setup (JUnit: global test suite setup via extensions or build scripts)

**Examples of Expensive External Resources**

- Database instances or containers (Postgres, MySQL)- External services / microservice mocks or real service endpoints- Selenium/WebDriver browser sessions or cloud browser farms- Message brokers (Kafka), large datasets, or hardware devices

**Cleanup & Leak-Prevention Strategies (SDET-focused)**

- Always provide teardown in fixtures (yield-based fixtures in PyTest; try/finally or @After in JUnit).- Use scope-appropriate setup: minimize session scope unless truly shared.- Isolate resources per test where feasible (use ephemeral containers via testcontainers).- Use unique names/ports and deterministic cleanup: stop containers, close DB connections, flush message queues.- Detect leaks: add assertions in teardown (no open connections), use resource trackers, and CI timeouts.- Parallel execution: avoid shared mutable state; use per-worker session IDs or worker-scoped fixtures (pytest-xdist worker_id) and atomic setup (mutex / per-worker resources).- Use retries and idempotent cleanup to handle flakiness; capture logs on failure for debugging.

I would implement yield fixtures for setup/teardown in PyTest and corresponding @AfterEach/@AfterAll in JUnit, prefer ephemeral containers for isolation, and add CI checks to detect leaked resources.

MediumTechnical

43 practiced

A critical UI test is failing intermittently in CI and developers rely on it for releases. Describe a step-by-step triage process to diagnose the failure, including data to capture, reproduction strategies, instrumentation to add, and criteria for quarantining versus fixing immediately.

Sample Answer

**Brief approach (goal)** I would triage to (1) gather deterministic evidence, (2) reliably reproduce, (3) add targeted instrumentation, and (4) decide quarantine vs immediate fix.

**Step-by-step triage**1. Capture baseline data - CI job metadata (branch, commit, node image, browser/version, container logs, timestamps). - Test-run artifacts: screenshots, full video, DOM snapshot, browser console, network HAR, test runner logs, and exit code. - Attach CI node’s system metrics (CPU, memory) and any test-timeouts.

2. Reproduce locally and in CI - Re-run failing CI job with same commit, browser, and environment matrix. - Run test in headed mode with debugger/DevTools; run with reduced parallelism. - Use stress runs and repeatBulk (100+ iterations) to surface frequency.

3. Isolate the failure - Bisect: run only this test, then progressively remove surrounding tests to find inter-test dependencies. - Replace flaky selectors (text/position) with robust ones (data-test-id), mock unstable external services, and toggle network throttling.

4. Instrumentation to add - Insert rich logs with timestamps and unique correlation IDs. - Capture element states (exists/visible/enabled), DOM snapshot before action, and timing of async waits. - Enable verbose browser logs, DevTools protocol traces, and HAR exports. - Add assertions that log contextual state rather than just failing. - Implement optional deterministic waits (polling with timeouts) instead of fixed sleeps.

5. Re-run and analyze - Aggregate artifacts across runs to find patterns (race conditions, environment spikes). - Use flaky-test detector to correlate author, test churn, or recent infra changes.

**Quarantine vs Immediate Fix criteria**- Quarantine when: failure frequency blocks pipeline (>1 per N runs) and root cause unclear or fix risky; mark with ticket, notify stakeholders, and require a guardrail (manual approval) for releases.- Fix immediately when: root cause is obvious and low-risk (selector change, timing adjustment, mock fix) or the test prevents critical releases and the fix can be validated quickly.

**Outcome and follow-up**- Add regression test and monitoring (daily repeat runs) after fix.- Document root cause, mitigation, and add a flaky-score to decide long-term test health.

EasyTechnical

48 practiced

In Python using Selenium WebDriver, implement a helper function wait_for_element(driver, locator, timeout_seconds) that waits for an element to be present and visible, uses explicit waits rather than sleep, logs useful context on timeout, and tolerates transient stale element errors. Provide clear pseudo-code or code that is production-safe.

Sample Answer

**Approach**Use Selenium explicit waits (WebDriverWait + expected_conditions) with a small retry loop to tolerate StaleElementReferenceException. On timeout, log locator, page URL, page source snippet, and optionally screenshot path to aid debugging.

**Code (production-safe helper)**

python

import logging
from selenium.common.exceptions import StaleElementReferenceException, TimeoutException
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

logger = logging.getLogger(__name__)

def wait_for_element(driver, locator, timeout_seconds=10, poll_frequency=0.5, take_screenshot_on_fail=True):
    """
    Waits for element to be present in DOM and visible.
    locator: tuple like (By.CSS_SELECTOR, 'selector')
    Returns the WebElement or raises TimeoutException with enriched logs.
    """
    attempts = 0
    max_attempts = 3
    last_exc = None

    while attempts < max_attempts:
        try:
            wait = WebDriverWait(driver, timeout_seconds, poll_frequency=poll_frequency,
                                 ignored_exceptions=(StaleElementReferenceException,))
            elem = wait.until(EC.visibility_of_element_located(locator))
            return elem
        except StaleElementReferenceException as e:
            attempts += 1
            last_exc = e
            logger.debug("StaleElementReference encountered, retrying (%d/%d)", attempts, max_attempts)
            continue
        except TimeoutException as e:
            # enrich logging and rethrow
            url = driver.current_url
            page_snippet = driver.page_source[:1000]
            logger.error("Timeout waiting for %s after %s s. URL: %s", locator, timeout_seconds, url)
            logger.debug("Page source (truncated): %s", page_snippet)
            if take_screenshot_on_fail:
                try:
                    path = f"screenshot_wait_{int(time.time())}.png"
                    driver.save_screenshot(path)
                    logger.info("Saved screenshot: %s", path)
                except Exception as s_err:
                    logger.warning("Failed to save screenshot: %s", s_err)
            raise e from last_exc or e

**Notes**- Uses explicit wait, no sleeps.- Retries on transient stale errors.- Logs contextual info to speed debugging.- Edge cases: dynamic frames (switch frame first), elements inside shadow DOM require different handling.

HardSystem Design

42 practiced

Design a canary deployment verification pipeline where automated tests act as gatekeepers for promoting a canary to full production or triggering automated rollback. Define health metrics to monitor, test types to run during canary, thresholds for roll forward versus rollback, and how to minimize risk of false rollback.

Sample Answer

**Clarify goal & constraints**As an SDET I’d build a pipeline that automatically verifies a canary (e.g., 5–10% traffic) and decides: promote or rollback within a time window (e.g., 15–60 min). Requirements: low false positives, fast feedback, auditable decisions, safe rollback.

**High-level pipeline**- Deploy canary to subset → mirror/route 5–10% traffic → run parallel gated checks → aggregate verdict → promote or rollback automatically + alerting.- Implement in CI/CD (Argo CD/Spinnaker/Jenkins X) with a verification service and stateful audit log.

**Health metrics to monitor**- Latency: p95 and p99 response time- Error rate: 4xx and 5xx per minute- Throughput: requests/sec and saturation- Business metrics: conversion rate, signups, cart failures- Resource metrics: CPU, memory, threadpool exhaust- Canary-specific: user-facing feature flags success rate

**Test types during canary**- Synthetic smoke/end-to-end tests (critical paths)- Contract tests for downstream services- Regression unit/integration as fast checks- Real user traffic canary analysis (shadow/mirroring)- Chaos/failure injection (limited) for resilience- Data validation tests for DB/schema changes

**Decision thresholds**- Rollforward if: no metric deviates >10% from baseline and p99 latency within +20ms, error rate delta <0.1% over baseline for 30m.- Rollback if: error rate increases >2x baseline OR absolute increase >1% AND sustained for 5 minutes; p99 latency degrades >50% sustained 10 minutes; business metric drop >5% in 30 minutes.- Use a scorecard: weighted metrics (errors 40%, latency 25%, business 25%, resources 10%) with promote threshold >=90, rollback <=70, otherwise hold and extend observation.

**Minimize false rollbacks**- Require sustained deviations (not single spike) and multiple metric confirmations.- Use statistical tests (e.g., sequential probability ratio test) vs baseline with confidence intervals.- Canary cohort diversity and multiple independent checks (synthetic + real traffic).- Allow manual override with quick rollback tooling and safe feature-flag kill-switch.- Gradual ramp (5→25→50%) with decision gates at each step.

**Instrumentation & observability**- Centralize metrics in Prometheus/Datadog, tracing in Jaeger, logs in ELK.- Automated alerting + runbook links; record full telemetry with trace IDs for root cause.

This design balances speed and safety, giving automated, statistically sound gating while enabling SDETs to tune weights, thresholds, and test coverage.

EasyTechnical

45 practiced

You are tasked with integrating automated tests into a CI system for a repo that currently has no automation. Describe an end-to-end plan to introduce tests into the pipeline, including PR gating strategy, parallelization, environment provisioning, artifact collection, failure handling, and rollout strategy to avoid blocking developers.

Unlock Full Question Bank

Get access to hundreds of Automation Testing and SDET Background interview questions and detailed answers.

Join thousands of developers preparing for their dream job.