CI/CD questions come up in almost every automation engineer interview. Interviewers want to know you can set up pipelines, debug failures, and optimize test execution. Here are the questions you will face.
Q: What CI/CD tools have you used for running Playwright tests?
A: GitHub Actions, Jenkins, and GitLab CI are the most common. GitHub Actions is the easiest to set up -- create a YAML workflow file, install browsers with --with-deps, run tests, upload artifacts. Jenkins uses a Jenkinsfile with the Playwright Docker image as the agent and publishHTML for reports. GitLab CI uses .gitlab-ci.yml with built-in JUnit reporting and artifact browsing. The core steps are the same across all tools: checkout code, install dependencies, install browsers, run tests, upload reports.
Q: How do you handle flaky tests in CI?
A: Three levels. First, set retries: 2 in playwright.config.ts for CI to automatically retry failed tests. This prevents false pipeline failures. Second, track which tests are retrying -- if the same test retries frequently, it has a real problem. Fix the root cause (race condition, timing issue, shared state). Third, use tags like @flaky to mark known flaky tests and run them separately. Never just increase retries and ignore the problem. A flaky test suite eventually becomes an ignored test suite.
Q: How do you reduce CI execution time for a large test suite?
A: Four strategies in order of impact. First, sharding -- split tests across multiple CI machines using --shard=1/4. Four shards = roughly 4x faster. Second, workers -- use fullyParallel: true and workers: "50%" to parallelize within each machine. Third, browser caching -- cache the Playwright browser binaries so they do not download on every run (saves 1-2 minutes). Fourth, targeted testing -- run only affected tests on PRs using grep or project filtering, and run the full suite on main branch merges.
Q: What is the difference between workers and sharding in Playwright?
A: Workers run multiple test files in parallel on the same machine. More workers = faster, but limited by CPU and memory. Sharding distributes test files across different CI machines. Each machine gets a subset of tests and runs them independently. Workers are configured in playwright.config.ts (workers: 4). Sharding is configured via CLI flag (--shard=1/4) and CI matrix strategy. You can combine both -- each shard uses multiple workers.
Q: A test passes locally but fails in CI. What do you do?
A: Step-by-step approach. First, read the CI error message and stack trace. Second, download the trace artifact and open it with npx playwright show-trace -- it shows every action, network request, and DOM snapshot. Third, check for common CI-specific issues: slower machines cause timeouts, different screen resolution affects visual tests, missing environment variables, network restrictions in CI. Fourth, if the trace does not help, reproduce locally using the same Docker image as CI. Fifth, once you identify the issue, fix it and ensure the test is environment-agnostic.
Q: What artifacts do you upload from CI for Playwright tests?
A: Three categories. First, HTML report -- upload with if: always() condition so it is available whether tests pass or fail. Retain for 14 days. Second, trace files and screenshots -- upload with if: failure() to save storage. Trace files are the most powerful debugging tool -- they replay the entire test execution step by step. Retain for 7 days. Third, for sharded runs, upload blob reports from each shard and merge them in a separate job using npx playwright merge-reports.
Q: How do you run Playwright tests in Docker?
A: Use the official Playwright Docker image: mcr.microsoft.com/playwright:v1.48.0-jammy. It has all browsers and system dependencies pre-installed. For simple runs, mount your project as a volume and run npm ci && npx playwright test. For full-stack testing, use docker-compose with containers for the app, database, and Playwright tests. The test container uses wait-on to wait for the app to be ready. Always pin the image version and set CI=true.
Q: What is the blob reporter and when do you use it?
A: The blob reporter produces a compact binary format containing all test results, traces, and attachments. You use it when sharding tests across multiple CI machines. Each shard produces a blob report. After all shards complete, a separate merge job downloads all blob reports and runs npx playwright merge-reports --reporter html to combine them into a single HTML report. Without blob reporter, you would have 4 separate HTML reports with partial results -- blob makes them mergeable.
Key Point: CI/CD interview questions focus on three areas: setting up pipelines, debugging failures, and optimizing execution time. Know sharding, tracing, and the blob reporter inside out.
Key Point: Know how to set up CI pipelines, debug failures with traces, optimize with sharding and workers, and explain the blob reporter.
Answer all 5 questions, then submit to see your score.
1. What flag is required when installing Playwright browsers in CI to also install system dependencies?
2. What does forbidOnly: true do in Playwright CI configuration?
3. When using test sharding in GitHub Actions, what should fail-fast be set to?
4. Which Playwright reporter produces a mergeable format designed for combining sharded test results?
5. What is the difference between workers and sharding in Playwright?