Cross-Browser-Testing mit Playwright

1. Warum Cross-Browser-Testing für Magento-Shops unverzichtbar ist

In den meisten CI-Pipelines läuft die E2E-Suite standardmäßig nur gegen Chromium, weil es das schnellste und am wenigsten fehleranfällige Setup ist. Für einen Magento- oder Hyvä-Shop ist das ein gefährlicher blinder Fleck: Der Checkout, das kritischste Stück Code im gesamten Shop, muss in jedem Browser funktionieren, den echte Kunden tatsächlich benutzen - nicht nur in dem, der in der Pipeline am bequemsten ist. Ein einziger fehlgeschlagener Bezahlvorgang in Safari kostet real Umsatz, auch wenn derselbe Test in Chrome grün war.

Der Irrglaube „funktioniert in Chrome, funktioniert überall" hält besonders bei modernen CSS-Features wie gap in Flexbox, :has()-Selektoren oder nativen Formularelementen selten stand. Gerade Hyvä-Shops mit Tailwind CSS und Alpine.js nutzen viele moderne Browser-APIs, deren Unterstützung sich zwischen den Engines unterscheidet. Playwright löst das strukturelle Problem, das früher Selenium-Grid-Setups mit separaten Treibern pro Browser hatten: eine einzige API, ein Testcode, drei Engines.

2. Chromium, Firefox und WebKit: Wie sich die Engines wirklich unterscheiden

Hinter den drei Browsern, die Playwright steuert, stehen drei technisch unabhängige Rendering-Engines: Blink (Chromium, Basis für Chrome, Edge und die meisten anderen Chromium-Browser), Gecko (Firefox, komplett eigenständige Entwicklung von Mozilla) und WebKit (Safari, historisch mit Blink verwandt, aber seit der Abspaltung 2013 eigenständig weiterentwickelt). Jede Engine bringt eine eigene JavaScript-Engine mit: V8 bei Chromium, SpiderMonkey bei Firefox und JavaScriptCore bei WebKit - mit messbaren Unterschieden im Timing von Promises, Microtasks und requestAnimationFrame.

Wichtig für die Testpraxis: Playwright installiert eigene, gepatchte Builds von Chromium, Firefox und WebKit über npx playwright install, nicht die auf dem System installierte Safari-App. Das WebKit-Binary ist eine sehr gute Annäherung an Safari-Verhalten, aber nicht hundertprozentig identisch - insbesondere bei plattformspezifischen Features wie Passkeys oder bestimmten Medien-Codecs. Für die meisten Rendering- und JavaScript-Bugs reicht die Annäherung völlig aus, um echte Cross-Browser-Probleme frühzeitig zu erkennen.

3. Browser-spezifische Quirks, die echte Bugs verursachen

Bestimmte Quirks tauchen in der Praxis immer wieder auf und lohnen sich als gezielte Testfälle: native Formularelemente wie <input type="date"> oder <input type="color"> rendern in jedem Browser unterschiedlich und lassen sich in WebKit im Headless-Modus oft nicht über die native UI bedienen. Sticky-Positionierung innerhalb von Scroll-Containern, das Verhalten von overflow: hidden mit border-radius und die Sichtbarkeits-Schwellen von IntersectionObserver für Lazy-Loading unterscheiden sich messbar zwischen den Engines.

Für Hyvä-Shops besonders relevant: Alpine.js-Übergänge (x-transition) feuern in Firefox teils mit anderem Timing als in Chromium, was Tests mit festen waitForTimeout-Werten flaky macht. Auch focus-visible-Outlines für Tastaturnavigation unterscheiden sich, was Accessibility-Tests beeinflusst. Statt jeden Quirk zu raten, lohnt sich ein kurzer Blick in echte Bugreports pro Engine, bevor man Testfälle dafür schreibt.

import { test, expect } from '@playwright/test';

test('date picker accepts native input format', async ({ page, browserName }) => {
  // WebKit renders <input type="date"> without a native calendar widget in headless mode
  test.skip(browserName === 'webkit', 'Native date picker UI is not testable in headless WebKit');

  await page.goto('/checkout/shipping');
  await page.getByLabel('Delivery date').fill('2026-08-01');
  await expect(page.getByLabel('Delivery date')).toHaveValue('2026-08-01');
});

test('checkout total updates after quantity change', async ({ page, browserName }) => {
  await page.goto('/checkout/cart');
  await page.getByLabel('Quantity').fill('3');
  await page.getByRole('button', { name: 'Update cart' }).click();

  // Firefox fires the change event slightly later than Chromium/WebKit
  const timeout = browserName === 'firefox' ? 8000 : 5000;
  await expect(page.getByTestId('cart-total')).toContainText('149,70', { timeout });
});

import { test, expect } from '@playwright/test';

test('product grid uses flexbox gap consistently across engines', async ({ page, browserName }) => {
  await page.goto('/catalog/sneakers.html');

  const grid = page.getByTestId('product-grid');
  const cards = grid.getByTestId('product-card');
  const first = await cards.nth(0).boundingBox();
  const second = await cards.nth(1).boundingBox();

  if (!first || !second) {
    throw new Error('Product cards not visible');
  }

  // Older WebKit builds (below 14.1) ignored `gap` on flex containers entirely;
  // this guards against a regression that reintroduces a flex-based grid.
  const horizontalGap = second.x - (first.x + first.width);
  expect(horizontalGap).toBeGreaterThanOrEqual(16);

  test.info().annotations.push({
    type: `engine-${browserName}`,
    description: `measured gap: ${horizontalGap}px`,
  });
});

4. Browser-Matrix in playwright.config.ts konfigurieren

Playwright bildet die Browser-Matrix über das projects-Array in playwright.config.ts ab. Jedes Projekt kombiniert einen Browser-Typ (chromium, firefox, webkit) mit optionalen Device-Presets aus devices, etwa für Viewport-Größe, User-Agent oder Touch-Unterstützung. Über testMatch und testIgnore lässt sich pro Projekt zusätzlich steuern, welche Testdateien überhaupt laufen - sinnvoll etwa, um einen mobilen Checkout-Smoke-Test nur auf einem Mobile-Safari-Projekt auszuführen, statt die komplette Suite zu verdreifachen.

In der lokalen Entwicklung reicht meist ein einzelnes Projekt: npx playwright test --project=chromium läuft in Sekunden und liefert schnelles Feedback. Erst in der CI-Pipeline kommt die volle Matrix zum Einsatz, gesteuert über Umgebungsvariablen oder separate CI-Jobs pro Browser. Diese Trennung zwischen schnellem lokalem Feedback und vollständiger CI-Abdeckung ist der wichtigste Hebel, um Cross-Browser-Testing praktikabel zu halten, ohne die Entwicklungsgeschwindigkeit zu bremsen.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests/e2e',
  fullyParallel: true,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 4 : undefined,
  reporter: [['html', { open: 'never' }], ['github']],

  use: {
    baseURL: process.env.BASE_URL ?? 'https://shop.mironsoft.test',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
  },

  // Browser matrix: only test what real users actually use
  projects: [
    {
      name: 'chromium',
      use: { ...devices['Desktop Chrome'] },
    },
    {
      name: 'firefox',
      use: { ...devices['Desktop Firefox'] },
    },
    {
      name: 'webkit',
      use: { ...devices['Desktop Safari'] },
    },
    {
      name: 'mobile-safari',
      use: { ...devices['iPhone 14'] },
      // Only run the checkout smoke suite on mobile Safari, not the full suite
      testMatch: /checkout\.smoke\.spec\.ts/,
    },
  ],
});

5. Tests parallel über mehrere Browser hinweg ausführen

Playwright parallelisiert standardmäßig auf zwei Ebenen: über workers, die Testdateien gleichzeitig ausführen, und über projects, die dieselbe Suite gegen mehrere Browser laufen lassen. Mit fullyParallel: true laufen sogar einzelne Tests innerhalb einer Datei parallel statt seriell. Das bedeutet aber auch: Eine Matrix aus drei Browsern verdreifacht faktisch die Laufzeit, sofern nicht genügend Worker-Kapazität zur Verfügung steht - ein Faktor, der bei der CI-Kostenplanung oft unterschätzt wird.

Parallelität deckt zudem Bugs auf, die in seriellen Testläufen verborgen bleiben: gemeinsam genutzte Testdaten, race conditions beim Anlegen von Testkonten oder Rate-Limits auf der API-Seite. Für Magento-Shops empfiehlt sich daher pro Worker ein isolierter Testkunde und, wo möglich, eine isolierte Datenbank-Fixture, damit parallele Browser-Läufe sich nicht gegenseitig Bestellungen oder Warenkörbe überschreiben. Playwrights --shard-Flag teilt die Suite zusätzlich horizontal über mehrere CI-Runner auf, unabhängig von der Browser-Dimension.

6. Browser-Coverage anhand echter Nutzerdaten entscheiden

„Wir testen einfach alle Browser" klingt gründlich, ist aber selten die richtige Strategie. Realistischer ist es, die tatsächliche Browser-Verteilung der eigenen Nutzer aus Google Analytics 4, der Search Console oder Server-Logs auszuwerten und die Testmatrix daran auszurichten. Ein typischer deutscher B2C-Shop sieht etwa 60 Prozent Chrome, 15 bis 20 Prozent Safari (überwiegend mobil), einige Prozent Edge und häufig unter 5 Prozent Firefox - Zahlen, die sich je nach Zielgruppe deutlich verschieben können.

Eine pragmatische Regel: Engines mit einem Traffic-Anteil über einer definierten Schwelle, etwa 5 Prozent, bekommen ein eigenes Playwright-Projekt in der CI-Matrix. Alles darunter wird durch gelegentliche manuelle Stichproben statt durch automatisierte Vollabdeckung geprüft. Diese Entscheidung sollte man nicht einmalig treffen, sondern vierteljährlich anhand aktueller Analytics-Daten überprüfen, da sich Browser-Marktanteile insbesondere durch mobile Trends spürbar verschieben.

// Pull browser share from a GA4/Search Console export and derive a coverage threshold
const browserShare = [
  { browser: 'Chrome', engine: 'chromium', share: 0.61 },
  { browser: 'Safari', engine: 'webkit', share: 0.19 },
  { browser: 'Edge', engine: 'chromium', share: 0.09 },
  { browser: 'Firefox', engine: 'gecko', share: 0.06 },
  { browser: 'Samsung Internet', engine: 'chromium', share: 0.03 },
  { browser: 'Opera', engine: 'chromium', share: 0.02 },
];

// Only engines above 5% combined traffic get a dedicated Playwright project
const COVERAGE_THRESHOLD = 0.05;

const enginesToTest = browserShare
  .reduce((engines, entry) => {
    const existing = engines.get(entry.engine) ?? 0;
    engines.set(entry.engine, existing + entry.share);
    return engines;
  }, new Map())
  .entries();

for (const [engine, share] of enginesToTest) {
  if (share >= COVERAGE_THRESHOLD) {
    console.log(`Include ${engine} in CI matrix (${(share * 100).toFixed(1)}% of traffic)`);
  } else {
    console.log(`Skip ${engine} in CI, cover via manual smoke test only (${(share * 100).toFixed(1)}%)`);
  }
}

7. CI-Matrix-Strategie: Abdeckung gegen Kosten abwägen

Jeder zusätzliche Browser in der Matrix multipliziert CI-Minuten und damit direkt die Kosten der Pipeline. Eine bewährte Strategie: Bei jedem Pull Request läuft nur die schnelle Chromium-Suite als schnelles Feedback, während die vollständige Browser-Matrix nachts oder vor einem Release läuft. fail-fast: false in der Matrix-Strategie sorgt zudem dafür, dass ein fehlgeschlagener Firefox-Job nicht die laufenden WebKit- oder Chromium-Jobs abbricht - wichtig, um alle Browser-spezifischen Fehler in einem Durchlauf zu sehen statt sie einzeln nachzujagen.

Zusätzliches Sharding über --shard verteilt eine ohnehin schon nach Browser gesplittete Suite weiter über mehrere Runner, was die Wall-Clock-Zeit senkt, aber die Gesamtzahl der Runner-Minuten nicht reduziert. Caching der Browser-Binaries zwischen Pipeline-Läufen und das Überspringen der Matrix bei reinen Dokumentations-Änderungen über Path-Filter sind die wirksamsten Hebel, um die Kosten einer echten Cross-Browser-Matrix in Grenzen zu halten.

name: E2E Cross-Browser Tests

on:
  pull_request:
    branches: [main]

jobs:
  e2e:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        browser: [chromium, firefox, webkit]
        shard: [1/2, 2/2]
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: npm ci
      - run: npx playwright install --with-deps ${{ matrix.browser }}

      - name: Run Playwright tests
        run: >
          npx playwright test
          --project=${{ matrix.browser }}
          --shard=${{ matrix.shard }}

      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report-${{ matrix.browser }}-${{ strategy.job-index }}
          path: playwright-report/
          retention-days: 14

8. Browser-spezifische Testfehler debuggen

Schlägt ein Test nur in einem einzigen Browser fehl, ist der Trace Viewer der schnellste Weg zur Ursache: npx playwright show-trace trace.zip öffnet eine Zeitleiste mit DOM-Snapshots, Netzwerk-Requests und Konsolen-Logs für exakt den fehlgeschlagenen Testlauf. In der lokalen Entwicklung lässt sich derselbe Fehler mit npx playwright test --headed --project=webkit --debug reproduzieren, was den Playwright Inspector öffnet und Schritt-für-Schritt-Ausführung mit page.pause() erlaubt.

Die meisten browserspezifischen Fehlschläge sind in Wahrheit Race Conditions, die eine Engine schneller oder langsamer auflöst als eine andere - etwa weil WebKit ein Layout-Reflow anders priorisiert als Chromium. Feste waitForTimeout-Aufrufe verschleiern solche Probleme nur, statt sie zu lösen; robuster sind explizite Web-First-Assertions wie expect(locator).toBeVisible(), die automatisch bis zu einem Timeout retryen. Konsolen-Logs und Stacktraces unterscheiden sich zwischen Engines oft in Formulierung und Reihenfolge, was beim Vergleichen von Fehlermeldungen zwischen Browsern zu beachten ist.

9. Chromium, Firefox und WebKit im direkten Vergleich

Jede Engine hat eigene Stärken, eigene Fallstricke und eine unterschiedliche Priorität in der Testmatrix. Die folgende Übersicht fasst zusammen, worauf es bei jedem Browser konkret ankommt und wie die Coverage-Entscheidung typischerweise ausfällt.

In der Praxis lohnt sich die volle Matrix nicht für jede Testsuite gleichermaßen: Visuelle und Interaktions-Tests am Checkout profitieren am meisten von echter Cross-Browser-Abdeckung, während reine API- oder Backend-Tests browserunabhängig sind und gar nicht erst über Playwright-Projekte dupliziert werden sollten.

10. Zusammenfassung

Cross-Browser-Testing mit Playwright löst ein konkretes Risiko: Ein Shop, der nur in Chromium getestet wird, kann in Safari oder Firefox trotzdem kaputt sein, ohne dass die CI-Pipeline es bemerkt. Playwright macht diese Absicherung praktikabel, weil eine einzige Testsuite über das projects-Array in playwright.config.ts gegen Chromium, Firefox und WebKit läuft, ohne separate Treiber oder Testcode pro Browser. Gezielte Tests für bekannte Quirks wie native Formularelemente, Flexbox-gap oder Transition-Timing fangen genau die Bugs ab, die eine Single-Browser-Suite systematisch übersieht.

Der entscheidende Hebel für Nachhaltigkeit ist aber nicht die Vollständigkeit der Matrix, sondern ihre Begründung: Browser-Coverage sollte sich an echten Analytics-Daten orientieren statt an der Annahme, dass jeder Browser gleich wichtig ist. Eine schnelle Chromium-Suite pro Pull Request kombiniert mit einer vollständigen, nächtlichen Matrix balanciert Testtiefe und CI-Kosten - und macht Cross-Browser-Testing zu einem dauerhaften Teil der Pipeline statt zu einer einmaligen Fleißaufgabe.

11. FAQ: Cross-Browser-Testing mit Playwright