20 Playwright Trace, Debugging, and Flakiness Interview Scenarios

Debugging interviews reveal whether you can turn artifacts into a causal explanation. A trace is not the root cause, a retry is not the repair, and a green rerun does not erase the original failure. Senior engineers preserve the failing context, classify uncertainty, and change the smallest responsible layer.

Use these scenarios as incident drills. Begin from the reported symptom, identify the evidence available from that exact execution, reconstruct the timeline, and propose a remediation that would prevent recurrence without weakening the assertion.

Build an Evidence Chain

The official Playwright Trace Viewer guide describes traces as a post-run debugging tool with action, DOM snapshot, network, console, source, and metadata views. The interview standard is to connect those panels into a sequence: what state existed, what action was attempted, what the application did, and why the expected outcome did not arrive.

Evidence from a different retry, project, or environment can support a hypothesis, but it cannot silently replace the failed execution. Label what each artifact proves and what remains inferred.

Initial Failure Triage

1. Why should you read the original error and call log before rerunning locally?

The first report identifies the failed operation, locator resolution, assertion expectation, timeout boundary, and attempted waiting behavior. A local rerun may pass and destroy urgency without preserving the original state. I would record the project, retry number, commit, worker context, and last successful step, then use the call log to form an initial hypothesis. Rerunning is an experiment after evidence capture, not the opening move.

2. How would you reproduce a failure that occurs only in one Playwright project?

I would run the exact test with that project, configuration, data seed, and relevant concurrency. Browser engine, viewport, locale, permissions, base URL, and storage state can all alter the path. I would compare project metadata rather than assuming the test is browser-flaky. If reproduction still fails, use the CI trace as primary evidence and reproduce inside the same container or runner image when possible.

3. Why should artifact retention and secret handling be designed together?

Traces and network panels can contain URLs, headers, payloads, DOM content, and credentials. I would collect enough evidence for diagnosis while using test accounts, redacting sensitive attachments, restricting artifact access, and enforcing retention limits. Turning tracing off to avoid security work leaves failures opaque; retaining every successful run forever creates a different risk. The policy should be reviewed with both debugging and data ownership in mind.

Trace Viewer Reasoning

4. How would you use a trace to diagnose a click timeout?

I would select the click, inspect its locator, actionability log, and before-and-after snapshots, then check whether another element covered the target, it moved, or it never became enabled. Network and console panels may explain why state stalled. I would avoid jumping directly to force. The repair should target the overlay lifecycle, selector contract, or missing readiness signal that prevented a real user-like click.

5. Why are DOM snapshots useful but not identical to a live debugging session?

Snapshots let me inspect recorded structure around an action and compare before with after, which is excellent for reconstructing state. They do not recreate every server dependency, timer, extension, or continuously executing script as a live page would. I would use them to answer what the runner observed, then use Inspector or a controlled reproduction to test hypotheses requiring live interaction. Recorded evidence and live experimentation serve different stages.

6. How would the network panel help explain an empty results list?

I would locate the search request, inspect its timing, status, request parameters, and response body, and correlate it with the action that initiated search. A successful transport response may still contain the wrong tenant or empty fixture data. A failed request may reveal authentication or dependency behavior. I would add a user-facing assertion for the loaded state and attach a safe correlation ID, rather than asserting an implementation request in every test.

7. Why might trace on first retry miss the most valuable failure state?

That setting records the retry attempt, so a retry that passes may not contain the original failing attempt's exact timeline. It is often a pragmatic cost choice, but the limitation must be understood. For a focused unstable area, I might temporarily use failure-retaining capture or targeted tracing to preserve the initial failure, then return to the normal policy after diagnosis. More tracing has storage and runtime costs.

import { defineConfig } from '@playwright/test'

export default defineConfig({
  retries: process.env.CI ? 1 : 0,
  outputDir: 'test-results',
  use: {
    trace: 'retain-on-failure',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
  reporter: [
    ['list'],
    ['html', { outputFolder: 'playwright-report', open: 'never' }],
  ],
})

Inspector and UI Mode

8. How would you choose between Inspector and Trace Viewer?

Inspector is for live, paused execution where I can step, inspect locators, and interact with the current page. Trace Viewer is for post-run reconstruction, especially from CI. I would use the trace to form the failure hypothesis, then Inspector to test a revised locator or readiness condition. A fix validated only in a paused browser can be misleading because debugging changes timing, so normal-speed proof is still required.

9. How would you use UI Mode to narrow a flaky suite failure?

I would filter to the project, file, tag, or status, run the smallest reproducing group, and inspect the timeline across repeated attempts. Watch mode helps while refining the test, and the action, network, console, and attachment panels keep evidence near the source. I would also run the relevant neighboring tests when shared state is suspected; isolating one test can remove the interference that caused the suite-level failure.

10. Why is adding page.pause to committed test code not a debugging solution?

It requires interactive execution, changes timing, and stalls unattended CI. I would use it temporarily in a local experiment, then remove it and encode the learned readiness or assertion contract. The final test should create useful steps and artifacts without human intervention. Any debugging command left in production automation should fail review because it converts an intermittent problem into a guaranteed pipeline blockage.

Flakiness Classification

11. How would you distinguish a product race from a test race?

A product race is observable user behavior caused by application ordering, such as a save button enabling before data is durable. A test race waits on an unrelated or premature signal while the product behaves correctly. I would reconstruct the user-visible state and backend evidence, then repeat with controlled delays or concurrency. The classification depends on the contract, not on whether adding a wait happens to make the test pass.

12. Why do retries classify instability instead of repairing it?

A retry supplies another independent attempt and may protect a pipeline from one transient event, but it does not remove shared data, missing synchronization, product timing, or dependency failure. I would track passed, flaky, and failed outcomes separately, retain evidence, and set ownership for recurring flakes. Treating flaky as passed erases risk and makes retry count an accidental reliability budget.

13. How would you investigate failures that increase when tests run in parallel?

I would inspect account, tenant, file, port, and backend-resource ownership, then correlate failures by worker and shard. Unique test data should be derived from a run-aware namespace, not a process-global counter. I would reduce workers as a diagnostic control and restore concurrency after removing the collision. If the system has a real capacity limit, encode that limit intentionally instead of allowing random contention.

14. Why can an actionability timeout reveal a real application defect?

If a button remains covered, unstable, disabled, or detached, Playwright is describing conditions that can also block a user. I would inspect the overlay and transition state before weakening the action. Sometimes the test reached the screen too early; sometimes the application exposes an interactive control before it is usable. The evidence should decide. Forcing the click bypasses safeguards and can convert a useful symptom into a later, less diagnostic failure.

State and Dependency Failures

15. How would you debug a response wait that intermittently times out?

I would verify the response promise is created before the trigger, tighten its predicate to the intended method and URL, and inspect whether caching or a service worker eliminates the expected request. Then I would ask whether the UI outcome is a better contract. Waiting for implementation traffic is justified when that traffic matters, but it becomes brittle when the application can correctly satisfy the user through another path.

16. Why should authentication failures be separated from locator failures?

An expired or invalid session can redirect to login, leaving the expected dashboard locator absent. I would assert the authenticated landing state early, inspect response and storage evidence, and make authentication setup fail with a clear identity-safe message. Updating the dashboard selector would be irrelevant. Strong fixtures classify setup failure close to the cause and prevent business tests from reporting a cascade of misleading element timeouts.

17. How would you investigate a test that fails only after another file runs?

I would look for leaked server state, reused accounts, mutable environment flags, persistent browser data outside the isolated context, and cleanup that depends on success. Running both files in order can reproduce the dependency, but the goal is to remove it. I would add unique data and idempotent cleanup, then randomize or parallelize the pair during verification. Test order must not be the hidden fixture.

Durable Remediation

18. Why is replacing a locator with a long CSS chain often the wrong flaky-test fix?

The chain may match today's DOM while coupling the test to layout and ignoring why the semantic locator was ambiguous. I would inspect the accessible name and role, improve the product's testable semantics if needed, and scope the locator to a stable region. A selector should express user intent or a deliberate test contract. Uniqueness achieved through fragile ancestry can move the failure rather than eliminate it.

19. How would you prove that a flakiness fix works?

I would document the prior race or collision, create a targeted reproduction, apply the causal change, and run repeated tests under the relevant project, data, and concurrency conditions. The normal suite must also pass so the fix does not overfit. I would monitor recurrence by stable test identity and failure category. A batch of green reruns is useful evidence only when it exercises the condition that triggered the defect.

20. How would you establish a debugging policy for a large Playwright platform?

I would standardize step naming, project metadata, safe artifacts, correlation IDs, and retry classification, with retention based on diagnostic value and sensitivity. Teams need a triage rubric that separates product, test, environment, data, and capacity causes. Flakes receive owners and deadlines rather than permanent retries. Platform reports should make recurring signatures visible and measure time to diagnosis, not celebrate raw rerun success.

Debugging Interview Checklist

• Preserve the failed attempt before starting a new experiment.
• Match project, environment, data, and concurrency during reproduction.
• Use trace panels together to identify the first divergent state.
• Label facts from artifacts separately from hypotheses based on another run.
• Classify product, test, data, dependency, and capacity causes.
• Remove temporary pauses, forced actions, and blanket waits from the final fix.
• Verify under the condition that exposed the failure and monitor recurrence.

Turn Artifacts into Action

Finish the scenario with a falsifiable cause and a repair at the responsible boundary. Say which trace detail supports the conclusion, which experiment would disprove it, and how repeated execution will exercise the original condition. A senior debugger does not merely make the red test green; they leave the suite with stronger evidence, a clearer contract, and less uncertainty the next time something fails.