How do you scale a test automation framework across multiple teams or a large codebase?

The scaling problem: When 20 engineers each extend the same framework, you get 20 different patterns for the same problem, duplicate Page Objects, conflicting test data strategies, and a CI pipeline that takes 40 minutes.

Solutions:

1. Internal shared library:

// @company/test-utils — published to internal npm registry
{
  "exports": {
    "pages": "./src/pages/index.ts",
    "helpers": "./src/helpers/index.ts",
    "fixtures": "./src/fixtures/index.ts"
  }
}

Teams install a versioned package. Base pages, API clients, auth helpers, and custom fixtures are maintained centrally. Breaking changes are versioned — teams update on their own schedule.

2. Framework governance:

• An Architecture Decision Record (ADR) documents why POM was chosen, why DI is used, and what the folder structure convention is.
• A Test Champions model: one QA per team is the framework steward. They attend a cross-team sync, carry decisions back to their team, and PR-review framework changes.

3. Parallel execution + sharding:

# Playwright — shard across 4 CI agents
npx playwright test --shard=1/4   # agent 1
npx playwright test --shard=2/4   # agent 2

4. Page Object ownership: Define which team owns which page objects. A CODEOWNERS file enforces review:

# .github/CODEOWNERS
/pages/checkout/  @checkout-team
/pages/auth/      @auth-team

5. Linting and formatting: Shared .eslintrc and prettier config from the internal library. Pre-commit hooks (husky + lint-staged) prevent unformatted code from reaching the repo.

6. Test tagging for CI gating:

• @smoke — runs on every PR (fast)
• @regression — runs nightly (comprehensive)
• Team-specific tags — each team can run only their tests during local development