E2E-Testautomatisierung für Online-Shops

Deployments laufen ohne Wartungsfenster, ein Rollback ist eingeübt, das Monitoring meldet Ausfälle innerhalb von Sekunden. Eine Frage bleibt in vielen E-Commerce-Projekten trotzdem offen: Woran merkt jemand vor dem Livegang, dass der Checkout nicht mehr trägt? Genau diese Lücke schließen automatisierte Ende-zu-Ende-Tests, kurz E2E-Tests. Sie fahren die Bestellstrecke so ab, wie eine Kundin sie abfährt: Produkt suchen, in den Warenkorb legen, Adresse eingeben, Zahlart wählen, Bestellung abschicken. Dieser Beitrag zeigt, welche Pfade in die automatisierte Testreihe gehören, wie belastbare Testdaten entstehen, warum wacklige Tests gefährlicher sind als fehlende und an welcher Stelle der Freigabekette die Prüfung laufen sollte.

Warum die Bestellstrecke der teuerste blinde Fleck ist

Onlinehandel ist in Deutschland Alltag: 83 % der Bevölkerung im Alter von 16 bis 74 Jahren haben schon einmal etwas im Internet gekauft oder bestellt, das entspricht rund 52 Millionen Menschen (Statistisches Bundesamt). Innerhalb der letzten drei Monate vor der Befragung haben 67 % der gleichen Altersgruppe online eingekauft (Statistisches Bundesamt). Wer einen Shop betreibt, bedient also keinen Nischenkanal, sondern einen Regelweg. Fällt dieser Weg aus, fällt der Umsatz mit ihm aus, und zwar sofort und ohne Vorwarnung.

Gleichzeitig ist der Checkout die empfindlichste Strecke im ganzen System. Die durchschnittliche Abbruchquote im Warenkorb liegt bei 70,22 % (Baymard Institute); dieser Wert ist ein Mittel aus 50 einzelnen Untersuchungen zum Thema Warenkorbabbruch (Baymard Institute). Ein durchschnittlicher Checkout umfasst 5,1 Schritte und 11,3 Formularfelder, und 17 % der Nutzer haben eine Bestellung schon wegen der Komplexität des Checkouts abgebrochen (Baymard Institute). Auf einer Strecke, die ohnehin so viel Reibung erzeugt, kostet jeder technische Defekt doppelt. Wie sich die Reibung inhaltlich senken lässt, steht in unserem Beitrag zur Checkout-Optimierung; hier geht es um die Frage, wie Sie einen Defekt bemerken, bevor er live geht.

Welche Pfade automatisiert gehören

Vollständige Abdeckung ist weder erreichbar noch sinnvoll. E2E-Tests sind langsam, teuer im Unterhalt und empfindlich gegen Oberflächenänderungen. Der Nutzen entsteht dort, wo ein Ausfall Geld oder Rechtssicherheit kostet. Für einen Shop sind das erfahrungsgemäß fünf Strecken, und die Reihenfolge ihrer Umsetzung ergibt sich aus dem Schaden, den ein Ausfall anrichtet.

Die Priorität folgt der Umsatzwirkung, nicht der Komplexität. Eine kaputte Facettensuche ärgert; ein Checkout, der beim Absenden einen Serverfehler wirft, kostet den Tagesumsatz. Deshalb steht die Gastbestellung an erster Stelle: Sie ist der kürzeste Weg zum Geld und berührt trotzdem Preisberechnung, Steuerlogik, Versandregeln, Zahlungsanbindung und Bestellbestätigung. Wer nur einen einzigen Test automatisieren darf, automatisiert diesen.

1. Gastbestellung durchspielen - Artikel auf der Produktseite wählen, Menge ändern, Warenkorb prüfen, Adresse erfassen, Versandart und Zahlart wählen, bestellen, Bestellnummer und Summe auf der Bestätigungsseite gegen den erwarteten Wert vergleichen.
2. Angemeldete Bestellung durchspielen - mit einem Konto anmelden, gespeicherte Lieferadresse übernehmen, abweichende Rechnungsadresse setzen, bestellen, Bestellung anschließend in der Kontoübersicht wiederfinden.
3. Zahlung gegen die Testumgebung des Anbieters - Weiterleitung, erfolgreiche Zahlung, abgebrochene Zahlung und fehlgeschlagene Zahlung als drei getrennte Fälle. Der Abbruch ist der wichtigste davon, weil er den Warenkorb erhalten muss.
4. Registrierung und Passwortwechsel - Anlage eines Kontos mit einer frischen Adresse, Bestätigungslink aus dem Postfach der Testumgebung, Anmeldung mit dem neuen Passwort.
5. Kaufabbruch bei fehlendem Lagerbestand - Artikel mit Bestand 1 zweimal parallel in den Warenkorb legen und beide Bestellungen abschicken. Der zweite Vorgang muss sauber ablehnen statt zu überverkaufen.

Ein Pfad verdient besondere Aufmerksamkeit, weil er rechtlich aufgeladen ist: die Schaltfläche, mit der die Bestellung ausgelöst wird. Nach § 312j Absatz 3 BGB ist die Pflicht des Unternehmers nur erfüllt, wenn die Schaltfläche gut lesbar mit nichts anderem als den Wörtern „zahlungspflichtig bestellen“ oder einer entsprechenden eindeutigen Formulierung beschriftet ist (BGB). Diese Beschriftung überlebt Theme-Anpassungen, Übersetzungsläufe und Baukastenblöcke oft nicht. Ein automatisierter Test, der die Beschriftung der Schaltfläche wörtlich vergleicht, ist in zehn Zeilen geschrieben und verhindert einen Mangel, der den Vertragsschluss selbst betrifft.

Testdaten: der Punkt, an dem die meisten Strecken kippen

Die häufigste Ursache für unbrauchbare E2E-Tests sind nicht die Tests, sondern ihre Daten. Ein Test, der einen bestimmten Artikel in den Warenkorb legt, hängt an Bestand, Preis, Steuersatz, Sichtbarkeit, Kategoriezuordnung und Verkaufskanal dieses Artikels. Wird der Artikel im Produktivsystem gepflegt und der Testdatenbestand daraus kopiert, verändert jede Datenpflege das Testergebnis. Dann meldet die Testreihe einen Fehler, obwohl der Code unverändert ist - und das Vertrauen in die Meldungen sinkt mit jedem solchen Fall.

• Testdaten gehören in die Versionsverwaltung. Wer die Fälle als Datei neben dem Code ablegt, kann sie mit dem Code zusammen ändern und zurückrollen.
• Jeder Lauf beginnt auf einem definierten Stand. Datenbank aufsetzen, Datensatz einspielen, Index neu bauen. Ein Lauf, der auf dem Ergebnis des vorherigen Laufs aufsetzt, ist nicht wiederholbar.
• Jeder Test legt an, was er braucht. Ein Test, der ein Konto benötigt, erzeugt es selbst mit einer eindeutigen Adresse. Geteilte Konten führen dazu, dass zwei parallele Läufe sich gegenseitig stören.
• Keine echten Personendaten. Testadressen, Testkarten und Postfächer der Testumgebung. Produktivdaten in einer Testumgebung sind ein Datenschutzproblem und kein Testvorteil.
• Der Datensatz bildet die Kanten ab, nicht den Durchschnitt. Artikel mit Bestand 1, Artikel mit Staffelpreis, Artikel mit abweichendem Steuersatz, Warenkorb oberhalb der Versandkostengrenze.

#!/usr/bin/env bash
set -euo pipefail

# Jeder Lauf beginnt auf demselben Stand: Schema, Datensatz, Index.
bin/console database:migrate --all
bin/console fixtures:load --set=e2e-checkout
bin/console dal:refresh:index

# Der Datensatz enthält genau die Fälle, die die Strecke braucht:
# single-stock-item Bestand 1, prüft die Ablehnung beim Überverkauf
# tiered-price-item Staffelpreis ab 10 Stück
# reduced-tax-item abweichender Steuersatz
# free-shipping-cart Warenkorb über der Versandkostengrenze

bin/console cache:clear --env=test
echo "Testdatensatz bereit: $(date --iso-8601=seconds)"

Der zweite Stolperstein sind Zahlungen. Eine echte Zahlung darf in einem automatisierten Lauf nicht ausgelöst werden, eine übersprungene Zahlung prüft dagegen den entscheidenden Teil der Strecke nicht. Die Lösung liegt in den Testumgebungen der Zahlungsanbieter: Sie liefern Testkartennummern für Erfolg, Ablehnung und Zeitüberschreitung und spiegeln die Rückmeldungen an den Shop genauso, wie es der Produktivbetrieb tut. Damit lässt sich der komplette Rücksprung inklusive Statuswechsel der Bestellung prüfen, ohne dass Geld fließt.

Flakiness: warum grüne Läufe trügen können

Ein wackliger Test ist einer, der bei unverändertem Code mal besteht und mal fehlschlägt. Er ist schlimmer als ein fehlender Test, weil er das Vertrauen in die gesamte Testreihe untergräbt. Eine Auswertung des gesamten Testbestands bei Google aus dem Jahr 2016 beziffert den Anteil auf rund 1,5 % aller Testläufe, die ein wackliges Ergebnis melden (Google Testing Blog). Bezogen auf die Tests selbst betrifft das fast 16 % des Bestands, die eine gewisse Wackligkeit aufweisen (Google Testing Blog).

Noch aussagekräftiger ist der Anteil an den Fehlermeldungen: Etwa 84 % der beobachteten Wechsel von bestanden auf fehlgeschlagen gehen auf einen wackligen Test zurück (Google Testing Blog). Anders gesagt: Von sechs roten Läufen weist im Mittel nur einer auf einen echten Defekt hin. Die Rechnung dahinter ist ernüchternd - bei einem durchschnittlichen Projekt mit rund 1000 einzelnen Tests (Google Testing Blog) und einer Wackelquote von 1,5 % schlagen pro Lauf etwa 15 Tests fehl und binden teure Untersuchungszeit (Google Testing Blog).

• Feste Wartezeiten. Eine Pause von zwei Sekunden ist auf dem Entwicklungsrechner zu lang und auf der ausgelasteten Freigabemaschine zu kurz. Auf Bedingungen warten, nicht auf die Uhr.
• Animationen und nachgeladene Bereiche. Ein Knopf, der noch einblendet, nimmt den Klick entgegen und verliert ihn. Auf den fertigen Zustand warten, nicht auf die Sichtbarkeit.
• Gemeinsame Daten zwischen parallelen Läufen. Zwei Läufe, die denselben Artikel bestellen, treffen sich am Lagerbestand.
• Zeit und Zeitzone. Ein Test, der um Mitternacht anders rechnet, ist ein Test mit eingebautem Zufall. Zeit im Testlauf festnageln.
• Fremde Systeme ohne Testumgebung. Wenn ein Dienst nicht zuverlässig antwortet, gehört an seine Stelle eine kontrollierte Nachbildung - und ein eigener, seltener Lauf gegen das echte System.

// Auf Zustände warten, nicht auf Sekunden: die häufigste Ursache für
// wacklige Läufe ist eine feste Wartezeit.
test('guest checkout completes and shows the order number', async ({ page }) => {
  await page.goto('/p/single-stock-item');
  await page.getByRole('button', { name: 'In den Warenkorb' }).click();
  await expect(page.getByTestId('cart-count')).toHaveText('1');

  await page.goto('/checkout/confirm');
  await fillAddress(page, guestAddress());
  await page.getByLabel('Rechnung').check();

  // Rechtlich vorgeschriebene Beschriftung der Bestellschaltfläche
  const submit = page.getByTestId('confirm-submit');
  await expect(submit).toHaveText('zahlungspflichtig bestellen');

  await submit.click();
  await expect(page.getByTestId('order-number')).toHaveText(/^SW\d{5,}$/);
  await expect(page.getByTestId('order-total')).toHaveText('49,90 EUR');
});

Ausführung in der Freigabekette

Tests, die niemand abwartet, wirken nicht. Die Empfehlung aus der DORA-Forschung ist eindeutig: Die Testreihe soll schnell bleiben, Entwickelnde sollen in weniger als zehn Minuten eine Rückmeldung aus den automatisierten Tests bekommen, sowohl auf dem eigenen Rechner als auch aus der Freigabekette (DORA). Zehn Minuten sind für eine vollständige E2E-Reihe unrealistisch - deshalb wird sie gestuft. Schnelle Prüfungen laufen bei jeder Änderung, langsame vor der Freigabe, sehr langsame nächtlich.

stages: [quick, e2e, smoke]

unit:
  stage: quick
  script:
    - composer install --no-interaction
    - vendor/bin/phpunit --testsuite unit
  timeout: 5 minutes

e2e-core:
  stage: e2e
  script:
    - ./ci/seed-testdaten.sh
    - npx playwright test --project=chromium --grep @core
  artifacts:
    when: always
    paths: [playwright-report/, test-results/]
    expire_in: 14 days
  timeout: 20 minutes

smoke-preview:
  stage: smoke
  script:
    - npx playwright test --project=chromium --grep @smoke
  environment: preview
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Die Smoke-Stufe nach dem Ausrollen ist der Punkt, an dem E2E-Tests und Betrieb ineinandergreifen. Sie prüft nicht die Fachlogik, sondern die Frage, ob der ausgerollte Stand überhaupt bedienbar ist - und sie ist der Auslöser für den Rückfall auf den vorherigen Stand. In einer Umgebung mit Blau-Grün-Ausrollung entscheidet dieser Test darüber, ob der Verkehr auf die neue Seite umgelegt wird. Fällt er aus, bleibt der alte Stand aktiv, und niemand muss nachts von Hand eingreifen. Die technische Umsetzung des Umschaltens beschreibt der verlinkte Beitrag im Detail.

In dieselbe Stufe gehört ein Leistungsbudget. Als Zielwert für die Ladeerfahrung gilt ein Largest Contentful Paint von 2,5 Sekunden oder weniger (web.dev), gemessen am 75. Perzentil der Seitenaufrufe, getrennt nach Mobil- und Schreibtischgeräten (web.dev). Ein Smoke-Test, der den Wert für Startseite, Kategorieseite und Produktseite erhebt und bei Überschreitung eine Warnung auslöst, fängt Leistungsrückschritte ab, bevor sie im Monitoring als schleichender Trend auftauchen. Hintergrund zu den Messwerten selbst steht im Beitrag zu den Core Web Vitals.

Ein Detail entscheidet über den Nutzen der ganzen Kette: Der Lauf muss Beweismittel hinterlassen. Bildschirmfoto beim Fehlschlag, Aufzeichnung der Sitzung, Konsolenausgabe und die Antwortzeiten der beteiligten Anfragen. Ohne diese Ablage beginnt jede Fehlersuche mit dem Versuch, den Fehlschlag von Hand nachzustellen - und genau das gelingt bei einem wackligen Test selten. Wenn die Ursache im Datenzugriff liegt, hilft der Blick in das Langsamabfragen-Protokoll weiter, das denselben Zeitraum abdeckt.

Was manuell bleibt

Automatisierung ersetzt das Testen von Hand nicht, sie verschiebt es. Die DORA-Empfehlung nennt die manuellen Anteile ausdrücklich: exploratives Testen, Usability-Tests und Abnahmetests sollen über den gesamten Ablauf hinweg stattfinden (DORA). Der Grund ist einfach: Ein automatisierter Test prüft, was jemand vorher als richtig beschrieben hat. Er findet Abweichungen von der Erwartung, aber keine falschen Erwartungen. Was in der Erwartung fehlt, steht typischerweise auch im Lastenheft nicht - und fällt erst auf, wenn ein Mensch die Strecke ohne Skript abläuft.

Besonders deutlich wird die Grenze bei der Barrierefreiheit. Der Jahresbericht zu den meistbesuchten Startseiten weist im Mittel 56,1 erkannte Fehler pro Seite aus (WebAIM Million 2026), ein Anstieg um 10,1 % gegenüber der Auswertung des Vorjahres mit 51 Fehlern pro Seite (WebAIM Million 2026). Der Bericht hält gleichzeitig fest, dass alle automatisierten Werkzeuge Grenzen haben und sich nicht jeder Konformitätsverstoß maschinell erkennen lässt (WebAIM Million 2026). Eine automatisierte Prüfung in der Testreihe fängt die maschinell erkennbaren Verstöße ab; die Bedienbarkeit mit Tastatur und Vorleseprogramm bleibt eine Aufgabe für Menschen. Das Vorgehen dazu beschreibt unser Audit-Beitrag zur Barrierefreiheit.

• Erstbestellung eines echten Menschen auf einem echten Gerät nach jedem größeren Umbau
• Bedienung des Checkouts allein mit der Tastatur, einmal je Freigabezyklus
• Prüfung der Bestell- und Versandmails in mehreren Postfachprogrammen
• Sichtprüfung von Preisdarstellung, Grundpreis und Versandkostenhinweis auf schmalen Bildschirmen
• Exploratives Testen neuer Funktionen ohne Testplan, mit dem ausdrücklichen Auftrag, sie zu brechen
• Abnahme durch die Fachabteilung anhand echter Geschäftsvorfälle

Einführung in vier Wochen

Der Aufbau scheitert selten an der Technik und oft an der Reihenfolge. Wer mit einer breiten Abdeckung beginnt, hat nach drei Wochen 200 wacklige Tests und niemanden, der sie pflegt. Der tragfähige Weg beginnt mit einer einzigen Strecke, die verlässlich läuft, und wächst von dort. Diese Aufteilung hat sich in Entwicklungsprojekten bewährt:

1. Woche 1 - Fundament. Testumgebung aufsetzen, Testdatensatz als Datei anlegen, Aufsetzskript schreiben. Ergebnis: Ein Befehl erzeugt einen reproduzierbaren Stand.
2. Woche 2 - erste Strecke. Gastbestellung als einziger Test, zwanzigmal hintereinander laufen lassen. Erst wenn zwanzig von zwanzig Läufen bestehen, kommt der zweite Test dazu.
3. Woche 3 - Kernpfade und Kette. Angemeldete Bestellung, Zahlung mit den drei Ausgängen, Registrierung. Einbindung in die Freigabekette mit Ablage von Bildschirmfotos und Aufzeichnungen.
4. Woche 4 - Smoke und Rückfall. Smoke-Test gegen Vorschau und Livestand, Verknüpfung mit dem automatischen Rückfall, Festlegung der Zuständigkeit für rote Läufe.

Ab der fünften Woche entscheidet die Pflege über den Wert der Testreihe. Drei Kennzahlen genügen, um zu erkennen, ob sie gesund ist. Sie lassen sich aus den Berichten der Freigabekette ableiten und gehören in dieselbe Ablage wie die Betriebskennzahlen aus dem Lasttest vor der Hochsaison.

Eine Abdeckungsangabe in Prozent ist dagegen ein schlechter Steuerungswert für E2E-Tests. Sie belohnt viele kleine Tests und bestraft die wenigen langen Strecken, die den eigentlichen Nutzen tragen. Zielführender ist eine Liste der Geschäftsvorfälle, die ein Ausfall unmöglich machen würde, und daneben die Angabe, welcher davon automatisiert geprüft wird. Diese Liste versteht auch die Geschäftsführung - und sie eignet sich als Grundlage für einen Shop-Check, bei dem der Ist-Stand einmal von außen bewertet wird.