Playwright Framework Design, Parallelism, and CI Interview Questions

15 questions on page objects, test organization, parallel runs, sharding, retries, visual testing, reporting, and CI.

Published October 24, 2026 · Updated October 29, 2026 · 14 questions

1. 1. How do you structure a Playwright test suite?

   Group tests by feature in a tests folder, put page objects or component helpers in a pages folder, shared fixtures in a fixtures file, test data and configuration in their own folders, and keep helpers small. Tests should read like user stories and contain the assertions, while page objects hold locators and actions.

2. 2. How do you implement the Page Object Model in Playwright?

   Create a class that receives the page, defines locators in the constructor, and exposes methods for actions. Expose the page object to tests through a fixture.

   export class LoginPage {
     constructor(private page: Page) {}
     email = this.page.getByLabel('Email');
     password = this.page.getByLabel('Password');
     submit = this.page.getByRole('button', { name: 'Sign in' });
   
     async login(user: string, pass: string) {
       await this.email.fill(user);
       await this.password.fill(pass);
       await this.submit.click();
     }
   }

3. 3. How does Playwright run tests in parallel?

   Test files run in parallel across worker processes by default, and tests inside one file run in order in the same worker. Set fullyParallel: true to parallelize tests within files too, and control the number of workers with the workers option. Tests must be independent, so do not rely on order or shared state.

4. 4. What is test sharding?

   Splitting the suite across several machines, with each machine running a part: npx playwright test --shard=1/4. In CI you run one job per shard, then merge the blob reports into a single HTML report. It cuts wall-clock time for large suites.

5. 5. How do retries work, and should you use them?

   With retries set, a failed test is rerun, and tests that fail then pass are reported as flaky. Retries are useful in CI to absorb rare environmental issues, with traces captured on the first retry. They should not hide real instability: track flaky tests and fix their causes.

6. 6. How do you organize tests with tags, annotations, and projects?

   Add tags in the test title or details (for example @smoke) and run subsets with --grep. Use annotations such as test.skip, test.fixme, and test.slow for known states, and test.describe to group tests. Projects run the suite under different configurations: browsers, devices, or environments.

7. 7. How do you do visual regression testing?

   Use expect(page).toHaveScreenshot() or expect(locator).toHaveScreenshot(). The first run saves reference images, and later runs compare against them with a configurable threshold. Screenshots depend on fonts and rendering, so generate and compare them in the same environment, such as the CI Docker image, and mask dynamic areas.

8. 8. What reporters does Playwright provide?

   Built-in reporters include list, line, dot, html, json, junit, and github for annotations in GitHub Actions. The HTML report shows steps, errors, screenshots, videos, and traces. You can combine several reporters and add custom or third-party ones such as Allure.

9. 9. How do you run Playwright in CI?

   Install dependencies, install browsers with npx playwright install --with-deps (or use Microsoft's Playwright Docker image), run npx playwright test against a deployed or locally started app, and upload the HTML report and traces as artifacts. Use retries and tracing on first retry, and shard large suites across jobs.

   - run: npm ci
   - run: npx playwright install --with-deps
   - run: npx playwright test
   - uses: actions/upload-artifact@v4
     if: always()
     with:
       name: playwright-report
       path: playwright-report/

10. 10. How do you manage environments and secrets?

    Use baseURL and environment variables (loaded with dotenv or the CI secrets store) to switch environments, keep credentials out of the repository, and use separate projects or config files per environment. Never commit saved authentication state files, since they contain session tokens.

11. 11. How do you keep tests independent when they share a backend?

    Create unique data per test (random ids or names), set up data through the API rather than the UI, clean up afterwards or use disposable environments, and avoid assuming existing records. For tests that need exclusive resources, serialize them with test.describe.configure({ mode: 'serial' }) or limit workers for that project.

12. 12. What is component testing in Playwright?

    An experimental feature that mounts individual components from React, Vue, or Svelte in a real browser and tests them with the same API. It sits between unit tests and full end-to-end tests. Check the current documentation before depending on it, since it is still evolving.

13. 13. How do you test accessibility with Playwright?

    Use role-based locators, which already check that elements expose the right roles and names, and add the @axe-core/playwright package to run automated accessibility scans on pages or components. Automated checks find only part of the issues, so combine them with manual keyboard and screen reader testing.

14. 14. Cypress, Playwright, or Selenium: how would you choose?

    Playwright suits teams that want fast, reliable cross-browser tests with a modern runner and strong debugging. Cypress offers a polished developer experience for JavaScript front-end teams, with some limits around multi-tab and cross-origin flows. Selenium fits organizations with existing Java or C# suites, broad language needs, or a Grid and real-device infrastructure. A real answer weighs team skills, existing investment, and browser coverage.