Tiers Beat the Full Matrix

Depth matched to risk, not maximalism

Share

SIT proves the service layer. Users still use browsers across many regional sites - one shared frontend codebase, brand and locale as configuration. Fix one market, break another is a real failure mode. Running the full brand × locale × browser matrix every night is denial-of-service on engineering.

The E2E program uses tiers L0–L4 to widen coverage as release risk increases - companion to SIT, not a duplicate.

Here's what this piece covers: matrix overload, the tier model, relationship to SIT, and three lead habits. Spread triage (393 → 27 root causes) gets its own post - article 15.

Part of Field Notes: agentic delivery.


1. The leadership problem

PR gates that only exercise one primary locale give false confidence for multi-market launches. Marketing maintains a large UAT catalog; engineering needs automated traceability without running everything everywhere.

Wrong: "We test all sites equally every night."
Right: "L0 smoke on every deploy; L4 full path on cert weeks - same repo, different schedules."

The anti-pattern is matrix maximalism - raw failure count screams while spread tells the truth.


2. What the portfolio shows

e2e-program-portfolio-summary.md (May–Jun 2026) documents the architecture:

Fact Detail
Sites 92 regional sites, five brands
Codebase One Next.js app + one automation library
UAT catalog ~108 marketing cases; ~104 automated
Raw failures (cert week example) 393 before spread triage → ~27 root causes (team-measured)
flowchart TB CODE[One frontend codebase] --> S1[Site 1 - brand × locale] CODE --> S2[Site 2] CODE --> SN[… N sites] S1 --> T[L0–L4 tier schedules] S2 --> T SN --> T

3. Tier model L0–L4

Tier When it runs Depth Typical duration
L0 / L1 PR gate Home, nav, search, detail ~90s–6 min
L2 Develop branch Critical-path adjacent, more locales Wider, still bounded
L3 TEST Full UAT catalog subset Pre-release
L4 Cert / launch Many locales × browsers × viewports Highest risk weeks

Schedule depth to risk - not ego:

const TIERS = {
  L0: { on: ['pull_request'], locales: ['en-US'], browsers: ['chromium'] },
  L2: { on: ['push:develop'], locales: ['en-US', 'en-CA', 'fr-CA'], browsers: ['chromium'] },
  L4: {
    on: ['cert_week'],
    locales: ['en-US', 'en-CA', 'fr-CA', 'en-GB', 'de-DE'],
    browsers: ['chromium', 'firefox', 'webkit'],
  },
};

function shouldRun(tier, event) {
  return TIERS[tier].on.includes(event);
}

Same paths as SIT - different layer. SIT asserts API chains and read-back; E2E asserts what the user sees in the browser.

flowchart LR subgraph service["SIT - service layer"] API[Chain + read-back] end subgraph browser["E2E - browser layer"] UI[Playwright paths] end J[Same end-to-end map] --> API J --> UI

What broke: fringe locales failed after a "green" primary-market merge - tier design is the fix, not hero manual retest. Raw failure count misleads without spread triage (article 15).


4. Named pattern: tiered E2E (L0–L4)

Tiered E2E (L0–L4) - depth matched to risk, one codebase - not matrix maximalism every night.

Map UAT cases to automated tags. Gaps are explicit debt - not silent assumptions.


5. What I'd do as a lead

  1. Never ship shallow-tier confidence for a high-tier launch. Match gate depth to market risk.
  2. Map UAT cases to tags in the automation registry. If marketing cares and automation does not, say so in the release checklist.
  3. Pair E2E tiers with SIT phases - both gates, one master map.

Further reading