Intermittent Bugs

Introduction

Intermittent Bugs is a practical Playwright skill for engineers responsible for turning flaky red builds into clear, fixable root causes. Instead of memorizing syntax, learn the production reason behind it: what risk it reduces, what evidence it gives, and how it changes the way a team ships software.

Purpose of this lesson

Story: A team retried a failing test for two weeks. The trace showed the real issue in five minutes: an API returned 429 under parallel CI load. In this lesson, intermittent bugs require evidence, repetition, and environment comparison. That is the difference between a test that merely runs and a test that helps a team decide.

Understanding the topic

Why this exists: Intermittent bugs require evidence, repetition, and environment comparison. Debugging is a discipline: collect evidence, classify the failure, reproduce under matching conditions, then fix the cause rather than the symptom.

• Real problem solved: Intermittent Bugs reduces ambiguity when browser behavior, data, timing, or infrastructure changes.
• Production use: CI triage, flaky-test review, release blockers, incident retrospectives, and framework maintenance.
• Beginner misuse: Adding timeout or force clicks before reading the trace.
• Elite SDET move: Create a failure taxonomy and make every report map to selector, timeout, data, app, network, environment, or framework.

Visual explanation

Mental model:

Red test
  ↓
Trace + logs + network
  ↓
Failure category
  ↓
Minimal repro
  ↓
Targeted fix

Informative example

A practical example for Intermittent Bugs:

test("intermittent-bugs with debug evidence", async ({ page }, testInfo) => {
  page.on("console", msg => testInfo.attach("console", { body: msg.text() }));
  await page.goto("/intermittent-bugs");
  await expect(page.getByRole("main")).toBeVisible();
});

Execution workflow

Real-world use

In real teams, Intermittent Bugs matters because product code changes every week. The test must still tell a useful story: what user behavior was protected, what state was expected, what evidence was captured, and whether the failure belongs to the app, the test, the data, or the environment.

Best practices

• Open trace before editing code.
• Classify failures consistently.
• Preserve evidence from first failure and retry.
• Fix the smallest proven root cause.

Common mistakes

• Increasing timeouts without proof.
• Deleting tests that reveal real instability.
• Treating all flakes as automation bugs.

Debugging tips

• Open the trace first. Check the action timeline, DOM snapshot, network calls, console errors, and screenshot before changing code.
• Classify the failure: selector, timeout, app bug, test data, network mock, authentication, browser difference, or CI resource pressure.
• Prefer user-facing locators. If a selector is tied to DOM layout instead of user intent, it will age badly.
• Record evidence on every retry. A passing retry without evidence hides the real flake.
• Reproduce with the same browser project, viewport, storage state, baseURL, worker count, and environment variables.

Advanced interview questions

Summary

Intermittent Bugs is valuable when it makes browser automation faster, clearer, and easier to debug under real product change.