Question 1

The suite takes 45 minutes and the team complains. How do you speed it up?

Accepted Answer

In order: (1) measure — which tests are slowest (Playwright report duration sort); (2) move UI work to API — setup steps (login, data creation) via API and storageState; (3) parallelism — raise workers, then shard (4 machines ≈ 4x); (4) tier the suite — smoke on PRs, full nightly; (5) replace fixed sleeps with condition-based waits; (6) cut irrelevant external requests with route.abort. The biggest wins usually come from 2 and 3.

Question 2

A test fails in CI but passes locally. Your investigation steps?

Accepted Answer

I check the differences systematically: (1) open the trace/screenshot from CI artifacts — the actual state at failure; (2) environment differences: CI is slower (timing), headless mode, different viewport/locale/timezone, resource limits; (3) parallelism — more workers in CI, possible data collisions; (4) data differences — which environment CI targets; (5) reproduce — imitate CI conditions locally (headless, same env, --repeat-each). The most common culprits: timing (hidden sleeps/races) and shared test data.

Question 3

What conditions must hold for tests to serve as a release quality gate?

Accepted Answer

A gate only works on a trustworthy signal: (1) very low flaky rate (<1%) — otherwise "skipping red" gets normalised and the gate is meaningless; (2) speed — a duration that doesn't block developer flow; (3) coverage of critical flows — so green genuinely reassures; (4) clear ownership — who investigates red; (5) a bypass procedure — who can approve skipping in emergencies (logged). Technical side: branch protection + required checks. The cultural side matters more than the technical one.

CI/CD, parallelism and flaky tests

📚 Sources and documentation