Automation Testing and Debugging Questions

Focuses on methods and tooling for testing and debugging automated scripts and applications across environments and layers. Includes diagnosing flaky tests, analyzing test failures, reading and interpreting logs, setting breakpoints, using browser developer tools, capturing screenshots and video recordings, and using remote debugging approaches. Covers systematic root cause analysis to determine whether failures stem from test code, application code, environment or infrastructure, and strategies for isolating problems such as component level testing and reproducible minimal examples. Addresses cross layer troubleshooting across frontend, application programming interface, database and network components as well as platform specific testing considerations such as emulator versus real device behavior and mobile device operating system differences. Also includes best practices for test design, logging and monitoring, making test failures actionable for developers, and troubleshooting automation within continuous integration and continuous delivery pipelines and shared environments.

EasyTechnical

23 practiced

You receive a stack trace from a failing test run that contains both minified JavaScript frames and backend Python stack frames. Describe step-by-step how you would read and interpret the stack trace, determine whether the root cause is in test code or application code, and obtain source-mapped traces (symbolication) for the JavaScript frames to point to original source lines.

Sample Answer

**Overview / approach**I treat the trace as two linked puzzles: the Python frames show where the error bubbled up on the backend/test runner; the minified JS frames show browser/client-side failure. I proceed step-by-step to locate root cause and get symbolicated JS frames.

**Step-by-step**1. Quickly scan the Python stack (bottom→top): identify exception type, the failing test file/function, and the last app/test line executed. Note any calls into HTTP clients or test harnesses that interact with the frontend.2. Scan JS frames: confirm they are minified (short names, single-line locations). Note file names and line/col numbers and any sourceMappingURL hints.3. Decide responsibility: - If Python frame points to test assertion or test setup error, start in test code. - If Python shows server returned an error (500) or the test invoked a failing endpoint, investigate application backend. - If JS frames show client runtime error causing test failure (e.g., uncaught exception in browser), treat it as frontend/app issue; check whether test input triggered it.4. Reproduce locally: run failing test with increased verbosity, capture network traffic (HAR), and reproduce in a browser/devtools if applicable.

**Obtain source-mapped traces (symbolication)**1. Ensure source maps were generated in the build (webpack/rollup with devtool: 'source-map' or equivalent) and accessible from the minified file (sourceMappingURL).2. Use automated symbolication: - For Node/browser test runners: enable V8 source maps:

bash

node --enable-source-maps my-test-runner.js

- For browser traces: open Chrome DevTools, reproduce error; DevTools will use source maps to show original files. - Use CLI tools or services (sentry, bugsnag) to upload minified files + .map and automatically symbolicate.3. If no automatic mapping available, use source-map library to map line/col to original:

javascript

const { SourceMapConsumer } = require('source-map');
const consumer = await new SourceMapConsumer(fs.readFileSync('app.js.map','utf8'));
const pos = consumer.originalPositionFor({ line: minLine, column: minCol });

4. Replace minified locations in the trace with original file:line:col and re-evaluate root cause.

**Validation & next steps**- Once symbolicated, link failing JS line back to test inputs or backend responses that triggered it.- Add targeted unit/integration tests, assert better errors, and ensure CI archives source maps to aid future debugging.

EasyTechnical

28 practiced

As an SDET, list the specific logs and telemetry fields you would add both to automated tests and to the application under test to make failures actionable for a developer. Provide an example log line or JSON log format that links a test step to backend operations, including correlation IDs, test-run metadata, timestamps, environment, and severity.

Sample Answer

**Approach (brief)** As an SDET I add structured, correlated telemetry in both test runners and the application so failures are actionable—quickly map a flaky test to backend requests, traces, and environment state.

**Key fields to emit**

- Test-side fields: - test_run_id, test_case_id, test_step_id, suite_name - correlation_id (UUID propagated), start_ts, end_ts, duration_ms - outcome, retry_count, agent_id, git_commit, ci_job, node/os - captured_assertion, screenshot_url, logs_bucket_path - severity, tags (smoke/regression)

- App-side fields: - correlation_id, request_id, trace_id, parent_id - service, endpoint, http_method, status_code, latency_ms - db_query_id, cache_hit, error_code, stack_trace - env, pod_id/instance_id, git_commit

**Why** Shared correlation_id + git_commit + timestamps lets devs join test failure -> HTTP trace -> DB op quickly.

**Example JSON log linking test step to backend**

json

{
  "timestamp": "2026-03-03T12:34:56.789Z",
  "severity": "ERROR",
  "source": "test-runner",
  "test_run_id": "run-20260303-001",
  "test_case_id": "TC-123-login",
  "test_step_id": "step-2-post-login",
  "correlation_id": "a1b2c3d4-5678-90ab-cdef-111213141516",
  "git_commit": "9f8e7d6",
  "ci_job": "pipeline/45",
  "environment": "staging",
  "message": "Assertion failed: expected 200 but got 500",
  "backend": {
    "service": "auth-service",
    "endpoint": "/api/v1/login",
    "request_id": "req-7890",
    "trace_id": "trace-555",
    "status_code": 500,
    "latency_ms": 342,
    "instance_id": "pod-auth-3"
  },
  "artifacts": {
    "screenshot": "s3://tests/run-20260303-001/TC-123/step-2.png",
    "logs": "s3://tests/run-20260303-001/TC-123/step-2.log"
  },
  "duration_ms": 1200
}

**Practical tips**- Propagate correlation_id in test HTTP client headers (X-Correlation-ID).- Use structured JSON logs and index fields in observability (ELK/Datadog/Tempo).- Include git_commit + ci_job to quickly map failures to code/CI runs.

HardTechnical

23 practiced

Technical design/coding: Describe an architecture or provide pseudocode for a log ingestion pipeline that accepts logs from test runners, browser console/HARs, application servers, and mobile devices; normalizes timestamps and fields, deduplicates entries, and writes to a searchable store with alerting on failure spikes. Address ordering semantics, clock skew normalization, schema evolution, and retention policies.

Sample Answer

**Approach (high level)**

Design a streaming ingestion pipeline: collectors → normalization & dedupe → event time ordering buffer → enrichment/store → alerting. Emphasize resilient, observable components and schema versioning.

**Architecture components**- Ingest collectors (HTTP/gRPC / Kafka producers) per source (test runners, browsers, servers, mobile)- Normalizer service (parses different formats, converts to canonical schema)- Time-normalizer & ordering buffer (handles clock skew + out-of-order using watermarking)- Deduplicator (hash + bloom filter / idempotent store)- Searchable store (Elasticsearch / OpenSearch / ClickHouse) + cold storage for retention- Alerting service (aggregates errors/spike detection)

**Pseudocode (Python-like)**

python

# canonical schema
class LogEvent:
    source_id: str
    event_id: str      # stable when available
    ts_utc: datetime
    original_ts: datetime
    payload: dict
    schema_version: int

def normalize(raw):
    # parse, map fields, attach schema_version
    mapped = map_fields(raw)
    mapped['original_ts'] = parse_timestamp(raw)
    mapped['ts_utc'] = to_utc(mapped['original_ts'], raw['tz_offset'] or guess_clock_skew(raw))
    mapped['event_id'] = canonical_id(raw)
    return LogEvent(**mapped)

# ordering buffer with watermark
BUFFER = PriorityQueue() # by ts_utc
watermark = now_utc() - MAX_ALLOWED_DELAY
def ingest(event):
    BUFFER.push(event)
    flush_eligible()

def flush_eligible():
    while BUFFER.peek().ts_utc <= watermark:
        ev = BUFFER.pop()
        if not dedupe(ev):
            write_store(ev)

**Key design details**- Clock skew: record original_ts and source clock info; use NTP/heartbeat telemetry to compute per-source offset; fall back to cross-stream ordering heuristics and server-received time; keep original timestamp for audits.- Ordering semantics: use event-time ordering with watermarking (configurable max_delay, e.g., 30s–5m); trade-off between latency and correctness.- Deduplication: prefer stable event_id; otherwise content-hash + time-windowed bloom filter or idempotent writes to a dedupe DB (Redis/Scylla).- Schema evolution: store schema_version with each event; use schema registry + flexible fields (JSONB); provide migration adapters and backward/forward compatibility (defaulting, deprecation notes).- Retention: hot index (30d) in search; warm/cold tiers (archive to object store for 1y+); enforce TTL via index lifecycle management.- Alerting: stream-based metrics (error rate, failure spikes) with sliding windows and anomaly detection; alert on Delta(5m) > threshold and sustained CPU/backpressure; integrate to PagerDuty.

**Trade-offs**- Tighter watermarks → lower latency but risk out-of-order; longer buffers → higher memory/delay.- Dedup store consistency vs cost: Redis for speed, durable DB for correctness.

This design suits SDET needs: integrates with CI to tag test-run logs, supports reproducible timestamps for flaky test triage, and enables fast search + alerts for test failures.

MediumTechnical

27 practiced

A flaky integration test is failing due to a database race condition. Describe the evidence you would collect (query logs, deadlock traces, lock wait statistics), how to reproduce the race locally, and the SQL/database techniques (transaction isolation levels, SELECT ... FOR UPDATE, optimistic locking) or application-side mitigations you would consider to fix the root cause.

Sample Answer

**Situation & goal**I’m an SDET investigating a flaky integration test that intermittently fails due to a DB race. I’d collect evidence, reproduce the race locally, then suggest DB and app mitigations.

**Evidence to collect**- Query logs with timestamps and full SQL (slow-query and general logs).- DB lock/wait statistics (e.g., SHOW ENGINE INNODB STATUS; pg_stat_activity, pg_locks).- Deadlock traces and transaction IDs.- Application logs with correlation IDs and timestamps around test run.- Test timing/profile (thread interleaving, latency) and schema/index information.

**How to reproduce locally**- Capture the failing SQL sequence and order of operations.- Write a small harness that runs the concurrent sessions with the same SQL, using separate DB connections and controlled synchronization (barriers) so you can vary timing.- Use tooling: psql/mysql client scripts, pgbench, or a simple multithreaded pytest that spawns N workers and coordinates with threading.Barrier.- Add artificial delays (sleep) at critical points to force interleavings observed in logs.

**SQL / DB techniques**- Increase transaction isolation (e.g., SERIALIZABLE) to detect anomalies; be aware of performance and retry requirements.- Use SELECT ... FOR UPDATE to acquire row-level locks for rows you will modify:

sql

BEGIN;
SELECT * FROM accounts WHERE id = 42 FOR UPDATE;
UPDATE accounts SET balance = balance - 10 WHERE id = 42;
COMMIT;

- Optimistic locking via version/timestamp columns: check-and-update pattern:

sql

UPDATE orders SET status = 'processed', version = version + 1
 WHERE id = 7 AND version = 3;
-- check affected_rows == 1

- Use explicit transactions and keep them short; avoid user interaction inside transactions.- Use appropriate indexes to avoid unintended full-table locks.

**Application-side mitigations**- Retry transient failures with exponential backoff when deadlocks or serialization failures occur.- Serialize critical sections at application layer using distributed locks (Redis/RedLock) only when necessary.- Make tests deterministic: mock or stub external timing, seed DB to known state before each run, run the concurrent harness deterministically.- Add assertions in tests that detect stale reads and retry or fail fast with diagnostic logs.

**Why these steps**Collecting logs pinpoints which statements and locks collide; reproducing with controlled timing lets you validate fixes; DB-level locking and optimistic locking resolve consistency, while app-side retries and deterministic tests make flakes actionable and reliable.

EasyTechnical

29 practiced

For a UI test framework using Selenium or Playwright running in CI, describe how you would capture screenshots and video recordings for failed tests and automatically attach them to CI job artifacts. Explain where artifacts should be stored, naming conventions, retention policies, and strategies to limit storage cost (e.g., capture only on failure, compress, TTL).

Unlock Full Question Bank

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

Join thousands of developers preparing for their dream job.