Mobile-Web-Testing-Strategie fuer Responsive Shops

1. Warum Viewport-Resize allein nicht reicht

Der einfachste Weg, "mobile Tests" zu behaupten, ist cy.viewport('iphone-x') oder page.setViewportSize() vor eine bestehende Desktop-Testsuite zu setzen. Das prueft jedoch nur, ob das Layout bei schmalerer Breite nicht bricht - es sagt nichts darueber aus, ob Touch-Interaktionen funktionieren, ob die virtuelle Tastatur das Checkout-Formular verdeckt oder ob die Off-Canvas-Navigation den Body-Scroll korrekt sperrt. Ein Mobile-Web-Test muss echte mobile Interaktionsmuster abbilden, nicht nur ein verkleinertes Desktop-Layout.

Da die Mehrheit des E-Commerce-Traffics ueber Smartphones erfolgt, sollte die Priorisierung der E2E-Coverage das widerspiegeln: kritische Journeys wie Produktsuche, Warenkorb und Checkout verdienen dedizierte Mobile-Testfaelle, nicht nur eine Variante des Desktop-Tests mit anderem Viewport. In der Praxis zeigt sich, dass gerade Touch-spezifische Bugs, etwa ein Swipe-Karussell, das auf Maus-Events reagiert, aber keine Touch-Events verarbeitet, in reinen Resize-Tests unentdeckt bleiben und erst durch Nutzerbeschwerden auffallen.

Die folgenden Abschnitte behandeln konkrete Mobile-Web-Testing-Szenarien: von Touch-Gesten ueber mobile Navigationsmuster bis zur CI-Integration einer Device-Matrix. Cypress und Playwright dienen dabei als konkrete Werkzeuge, weil beide native Unterstuetzung fuer Touch-Emulation und Device-Presets mitbringen.

2. Touch-Gesten testen: Tap, Swipe und Long-Press

Ein click()-Aufruf in Cypress oder Playwright feuert ein Maus-Event, kein Touch-Event. Auf echten Geraeten loesen Interaktionen jedoch touchstart, touchmove und touchend aus, und JavaScript, das ausschliesslich auf mouseenter oder mousedown lauscht, reagiert auf Touch-Geraeten schlicht nicht. Playwright bietet dafuer die native page.touchscreen-API mit tap(), Locator.tap() sowie hasTouch: true in der Browser-Kontext-Konfiguration. Cypress benoetigt fuer realistische Touch-Simulation das Plugin cypress-real-events, das echte Betriebssystem-Events statt synthetischer DOM-Events erzeugt.

Swipe-Gesten fuer Produktbild-Karussells oder horizontal scrollende Kategorie-Chips lassen sich als Sequenz aus touchstart, mehreren touchmove-Schritten und touchend simulieren, wobei die X-Koordinate schrittweise verschoben wird. Long-Press-Interaktionen, etwa fuer eine Quick-View-Vorschau auf Produktkarten, erfordern eine definierte Haltezeit zwischen touchstart und touchend, meist zwischen 500 und 800 Millisekunden. Wichtig ist, diese Gesten nicht nur technisch auszuloesen, sondern auch das erwartete visuelle Feedback zu pruefen, etwa ob eine Ripple-Animation oder ein Kontextmenue tatsaechlich erscheint.

// cypress/support/commands.js
// Custom command: simulate a realistic swipe gesture on a carousel
Cypress.Commands.add('swipeLeft', { prevSubject: 'element' }, (subject) => {
  const el = subject[0];
  const rect = el.getBoundingClientRect();
  const startX = rect.right - 20;
  const endX = rect.left + 20;
  const y = rect.top + rect.height / 2;

  cy.wrap(subject)
    .trigger('touchstart', { touches: [{ clientX: startX, clientY: y }] })
    .trigger('touchmove', { touches: [{ clientX: startX - 60, clientY: y }] })
    .trigger('touchmove', { touches: [{ clientX: endX, clientY: y }] })
    .trigger('touchend');
});

// Usage in a test
cy.get('[data-testid="product-image-carousel"]').swipeLeft();
cy.get('[data-testid="carousel-slide-2"]').should('be.visible');

// Playwright: native touchscreen API with long-press for quick view
test('long press on product card opens quick view', async ({ page }) => {
  const card = page.getByTestId('product-card-1');
  const box = await card.boundingBox();
  await page.touchscreen.tap(box.x + box.width / 2, box.y + box.height / 2);
  await page.waitForTimeout(650); // hold duration for long-press
  await expect(page.getByTestId('quick-view-modal')).toBeVisible();
});

3. Mobile Navigation: Hamburger-Menue und Off-Canvas

Mobile Navigationsmuster unterscheiden sich fundamental von Desktop-Dropdowns: Statt einer Hover-Interaktion oeffnet ein Tap auf das Hamburger-Icon ein Off-Canvas-Panel, das ueber den sichtbaren Bereich einblendet. E2E-Tests muessen pruefen, dass das Panel korrekt einfaehrt, dass der Body-Scroll waehrend der offenen Navigation gesperrt ist und dass ein Tap ausserhalb des Panels oder auf ein Close-Icon es wieder schliesst. Besonders wichtig bei Hyvä-Themes mit Alpine.js: Der x-show-Zustand des Off-Canvas-Panels sollte per data-testid oder ARIA-Attribut pruefbar sein, nicht ueber fragile CSS-Klassen-Selektoren.

Verschachtelte Kategoriebaeume werden auf Mobile haeufig als Akkordeon statt als Mega-Menue dargestellt. Ein Testfall sollte pruefen, dass das Aufklappen einer Unterkategorie die uebergeordnete Ebene nicht schliesst und dass mehrstufige Navigation ohne Verlust des Scroll-Zustands funktioniert. Zusaetzlich gehoert die Fokus-Falle (Focus Trap) zu den kritischen Pruefpunkten: Solange das Off-Canvas-Menue geoeffnet ist, darf Tab-Navigation nicht auf Elemente hinter dem Overlay springen, da sonst Screenreader-Nutzer und Tastaturnutzer die Seite hinter dem Menue bedienen, ohne es zu sehen.

// Playwright: verify off-canvas navigation and body scroll lock
test('hamburger menu opens off-canvas nav with scroll lock', async ({ page }) => {
  await page.goto('/');
  const nav = page.getByTestId('offcanvas-nav');
  await expect(nav).toBeHidden();

  await page.getByTestId('hamburger-toggle').tap();
  await expect(nav).toBeVisible();

  // Body scroll must be locked while the panel is open
  const overflow = await page.evaluate(() => document.body.style.overflow);
  expect(overflow).toBe('hidden');

  // Tapping outside the panel closes it again
  await page.mouse.click(10, 10);
  await expect(nav).toBeHidden();
});

// Nested accordion category should not collapse the parent level
test('expanding a subcategory keeps parent level open', async ({ page }) => {
  await page.getByTestId('hamburger-toggle').tap();
  await page.getByTestId('category-women').tap();
  await page.getByTestId('subcategory-shoes').tap();
  await expect(page.getByTestId('category-women-panel')).toBeVisible();
  await expect(page.getByTestId('subcategory-shoes-panel')).toBeVisible();
});

4. Mobile Checkout UX: Autofill und Tastaturtypen

Der Checkout ist die Journey mit dem hoechsten Business-Impact, und auf Mobile entscheidet oft die richtige virtuelle Tastatur ueber Abbruch oder Kauf. Ein Telefonfeld ohne type="tel" oder inputmode="tel" oeffnet die volle QWERTZ-Tastatur statt des Ziffernblocks, eine E-Mail-Adresse ohne type="email" zeigt kein @-Symbol in der Tastenreihe. E2E-Tests sollten diese Attribute explizit als Assertion pruefen, denn ein visuell korrektes Feld kann trotzdem das falsche inputmode gesetzt haben und dadurch die Eingabe auf echten Geraeten spuerbar verlangsamen.

Ebenso wichtig sind autocomplete-Attribute wie autocomplete="postal-code" oder autocomplete="cc-number", die native Browser-Autofill und Passwortmanager-Integration ermoeglichen. Ein weiterer mobiler Sonderfall: Die virtuelle Tastatur nimmt oft ein Drittel bis die Haelfte des Viewports ein und kann den Absenden-Button ausserhalb des sichtbaren Bereichs schieben. Ein Test sollte nach dem Fokussieren eines Feldes pruefen, ob der naechste Call-to-Action noch erreichbar ist, etwa durch automatisches Scrollen zum fokussierten Element. Auch die Erreichbarkeit mit dem Daumen bei One-Hand-Bedienung ist ein Kriterium, das sich zumindest ueber die Position wichtiger Buttons im unteren Viewport-Drittel pruefen laesst.

// Cypress: verify correct keyboard types and autofill attributes at checkout
describe('mobile checkout form', () => {
  beforeEach(() => {
    cy.viewport('iphone-x');
    cy.visit('/checkout');
  });

  it('uses the correct inputmode and autocomplete per field', () => {
    cy.get('[data-testid="input-email"]')
      .should('have.attr', 'type', 'email')
      .and('have.attr', 'autocomplete', 'email');

    cy.get('[data-testid="input-phone"]')
      .should('have.attr', 'inputmode', 'tel')
      .and('have.attr', 'autocomplete', 'tel');

    cy.get('[data-testid="input-postal-code"]')
      .should('have.attr', 'inputmode', 'numeric')
      .and('have.attr', 'autocomplete', 'postal-code');

    cy.get('[data-testid="input-card-number"]')
      .should('have.attr', 'inputmode', 'numeric')
      .and('have.attr', 'autocomplete', 'cc-number');
  });

  it('keeps the submit button reachable when the keyboard is focused', () => {
    cy.get('[data-testid="input-email"]').focus();
    cy.get('[data-testid="checkout-submit"]').should('be.visible');
  });
});

5. Viewport-Konfiguration und Device-Matrix

Ein einzelner Mobile-Viewport reicht nicht aus, um reale Nutzung abzubilden. Kleine Geraete wie das iPhone SE mit 375 Pixel Breite offenbaren Layout-Probleme, die auf einem iPhone 14 Pro Max mit 430 Pixeln nicht sichtbar sind. Playwright liefert mit dem devices-Katalog fertige Presets inklusive Viewport, User-Agent, deviceScaleFactor und hasTouch, sodass sich Tests ueber mehrere reale Geraeteprofile parametrisieren lassen, statt nur eine willkuerliche Pixelbreite zu setzen. Cypress erlaubt aehnliche Presets ueber cy.viewport('iphone-x'), benoetigt fuer echte Touch-Faehigkeit aber zusaetzlich das erwaehnte Real-Events-Plugin.

Ein haeufig uebersehener Faktor ist der deviceScaleFactor: Bilder und Icons, die auf einem Standard-Display scharf wirken, koennen auf hochaufloesenden Mobile-Displays verpixelt erscheinen, wenn keine srcset-Varianten existieren. Auch die Meta-Viewport-Deklaration selbst gehoert zu den pruefbaren Aspekten: Ein fehlendes oder fehlerhaftes <meta name="viewport" content="width=device-width, initial-scale=1"> fuehrt dazu, dass mobile Browser die Seite herunterskalieren, statt sie nativ im Geraete-Viewport darzustellen - ein Test, der die berechnete Layout-Breite gegen die erwartete Viewport-Breite prueft, deckt solche Regressionen zuverlaessig auf.

// playwright.config.js
// Parametrize the same test suite across multiple real device profiles
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './e2e',
  projects: [
    {
      name: 'iphone-se',
      use: { ...devices['iPhone SE'] }, // smallest common mobile width, 375px
    },
    {
      name: 'pixel-7',
      use: { ...devices['Pixel 7'] }, // current Android flagship
    },
    {
      name: 'ipad-mini',
      use: { ...devices['iPad Mini'] }, // tablet breakpoint, 768px
    },
  ],
});

// Assert the viewport meta tag is present and correctly configured
test('viewport meta tag prevents mobile browser downscaling', async ({ page }) => {
  await page.goto('/');
  const content = await page.getAttribute('meta[name="viewport"]', 'content');
  expect(content).toContain('width=device-width');
  expect(content).toContain('initial-scale=1');
});

6. Tap-Targets und Barrierefreiheit auf Mobile

Die WCAG-Erfolgskriterien 2.5.5 und 2.5.8 definieren Mindestgroessen fuer interaktive Elemente: 44 mal 44 CSS-Pixel als Zielwert, 24 mal 24 Pixel als Minimum mit ausreichendem Abstand zu Nachbarelementen. Auf Mobile ist das keine Kuer, sondern eine funktionale Notwendigkeit, denn ein Daumen deckt physisch deutlich mehr Flaeche ab als ein Mauszeiger. Zu eng beieinanderstehende Icons in einer Produktkarte, etwa Merkzettel- und Warenkorb-Symbol nebeneinander, fuehren zu Fehltaps und damit zu Frustration und Kaufabbruch.

E2E-Tests koennen Tap-Target-Groessen automatisiert pruefen, indem sie die boundingBox() jedes interaktiven Elements auslesen und gegen den Schwellenwert von 44 Pixeln assertieren. Der Abstand zwischen zwei benachbarten Tap-Targets laesst sich ueber die Differenz der Bounding-Box-Koordinaten berechnen. Solche Assertions lassen sich als wiederverwendbare Hilfsfunktion in die Testsuite integrieren und auf alle interaktiven Elemente einer Seite anwenden, statt sie einzeln von Hand zu pruefen - ein Ansatz, der sich gut mit automatisierten Accessibility-Scans wie axe-core kombinieren laesst, welches allerdings Tap-Target-Abstaende nicht vollstaendig abdeckt.

7. Mobile Core Web Vitals und Performance-Assertions

Mobile Core Web Vitals unterliegen denselben Schwellenwerten wie Desktop, LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1, werden aber unter deutlich haerteren Bedingungen gemessen: langsamere CPUs, variable Mobilfunknetze und haeufig aktivierter Sparmodus, der Taktraten drosselt. Ein Test, der ausschliesslich auf einer schnellen Desktop-Maschine ohne Drosselung laeuft, unterschaetzt die tatsaechliche mobile Nutzererfahrung systematisch. Playwright erlaubt ueber die Chrome-DevTools-Protocol-Anbindung CPU-Throttling und Netzwerk-Drosselung auf simulierte 4G-Bedingungen, um realistischere Messwerte zu erzeugen.

In der Praxis empfiehlt sich, Performance-Budgets als harte Assertions in die Mobile-E2E-Suite zu integrieren, statt sie nur manuell in Lighthouse zu pruefen. Ein Test kann etwa nach dem Laden der Produktseite die LargestContentfulPaint-Metrik ueber die Performance-API auslesen und gegen ein Budget von 2500 Millisekunden pruefen. Auch die Zeit bis zur Interaktivitaet nach einem Tap auf den "In den Warenkorb"-Button laesst sich messen, indem die Zeitspanne zwischen Tap-Event und sichtbarer UI-Reaktion, etwa einer Mini-Cart-Aktualisierung, erfasst wird. Solche Assertions fangen Performance-Regressionen ab, bevor sie in Produktion landen.

8. CI-Pipeline fuer die Mobile-Device-Matrix

Eine einzelne Mobile-Konfiguration in der CI-Pipeline reicht nicht aus, um die Vielfalt echter Geraete abzudecken. Sinnvoll ist eine Matrix aus mindestens drei Profilen: ein kleines Geraet wie iPhone SE, ein aktuelles Flaggschiff wie Pixel 7 und ein Tablet-Breakpoint, da manche Layouts erst zwischen 768 und 1024 Pixel Breite brechen. Playwright unterstuetzt Matrix-Testing nativ ueber die projects-Konfiguration in playwright.config.js, wobei jedes Projekt ein eigenes Device-Preset referenziert und parallel ausgefuehrt wird.

Ein haeufiges Problem in CI-Umgebungen ist Flakiness durch Netzwerk-Throttling-Simulation: Wird CPU- und Netzwerkdrosselung zu aggressiv konfiguriert, schlagen Timing-abhaengige Assertions inkonsistent fehl. Bewaehrt hat sich, Throttling-Tests von funktionalen Mobile-Tests zu trennen und mit grosszuegigeren Timeouts sowie einer begrenzten, aber sinnvollen Retry-Strategie auszustatten. Die Testberichte sollten pro Geraeteprofil aufgeschluesselt werden, damit ein Fehlschlag auf dem kleinen Viewport nicht in den Ergebnissen der groesseren Geraete untergeht.

# .github/workflows/mobile-e2e.yml
name: Mobile E2E Device Matrix
on: [pull_request]

jobs:
  mobile-tests:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        device: [iphone-se, pixel-7, ipad-mini]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps chromium webkit

      # Run only the project matching the current matrix device
      - name: Run mobile E2E suite
        run: npx playwright test --project=${{ matrix.device }}

      - name: Upload report for this device
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-report-${{ matrix.device }}
          path: playwright-report/
          retention-days: 14

9. Mobile-Testing-Strategien im Vergleich

Der Unterschied zwischen einer oberflaechlichen und einer belastbaren Mobile-Web-Testing-Strategie zeigt sich am deutlichsten im direkten Vergleich einzelner Testaspekte. Die folgende Tabelle stellt den naiven Resize-only-Ansatz den mobil-spezifischen Testpraktiken gegenueber, die in diesem Artikel behandelt wurden.

Die Tabelle macht deutlich: Reines Resize-Testing prueft Layout, aber keine Interaktion. Eine belastbare Mobile-Web-Testing-Strategie kombiniert Touch-Simulation, mobile Navigationsmuster, Checkout-spezifische Formularpruefungen und gedrosselte Performance-Messungen in einer Device-Matrix, statt sich auf eine einzelne, verkleinerte Desktop-Ansicht zu verlassen.

10. Zusammenfassung

Eine belastbare Mobile-Web-Testing-Strategie fuer Responsive Shops geht deutlich ueber das Verkleinern des Viewports hinaus. Touch-Gesten wie Tap, Swipe und Long-Press muessen ueber native Touch-APIs simuliert werden, da Maus-Events auf echten Geraeten nicht ausgeloest werden. Mobile Navigationsmuster wie Hamburger-Menues und Off-Canvas-Panels benoetigen eigene Testfaelle fuer Scroll-Lock und Focus-Trap. Checkout-Formulare entscheiden mit korrekten inputmode- und autocomplete-Attributen ueber Conversion, und mobile Core Web Vitals muessen unter realistischer CPU- und Netzwerkdrosselung gemessen werden.

Der groesste Hebel liegt in der Priorisierung: Da die Mehrheit des E-Commerce-Traffics mobil ist, verdienen kritische Journeys dedizierte Mobile-Testfaelle statt einer nachtraeglichen Resize-Variante bestehender Desktop-Tests. Eine Device-Matrix in der CI-Pipeline, mit kleinen und grossen Geraeten sowie Tablet-Breakpoint, deckt Layout- und Interaktionsprobleme ab, die auf einem einzelnen Viewport unsichtbar bleiben.

11. FAQ: Mobile-Web-Testing-Strategie fuer Responsive Shops