DSGVO-Cookie-Consent-Banner automatisiert testen

1. Rechtliche Anforderungen kurz eingeordnet

Nach der Datenschutz-Grundverordnung und dem Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz dürfen nicht technisch notwendige Cookies, etwa für Marketing- oder Analyse-Tracking, erst nach einer aktiven, informierten und freiwilligen Einwilligung der Nutzerin oder des Nutzers gesetzt werden, wobei die blosse Weiternutzung der Seite ausdrücklich keine gültige Einwilligung darstellt und ein Ablehnen genauso einfach möglich sein muss wie ein Zustimmen.

Diese Anforderung betrifft nicht nur das sichtbare Setzen eines Cookies im engeren Sinne, sondern jedes Nachladen eines Skripts, das personenbezogene Daten an einen Drittanbieter überträgt, etwa ein Google-Analytics-Snippet, ein Facebook-Pixel oder ein Retargeting-Skript, weshalb technisch betrachtet nicht der Cookie selbst, sondern der tatsächliche Netzwerkaufruf des jeweiligen Tracking-Skripts der entscheidende, prüfungsrelevante Vorgang ist. Dieser rechtliche Rahmen ist hier bewusst nur kurz eingeordnet, ersetzt aber keine individuelle Rechtsberatung für das jeweilige Projekt, da sich Detailanforderungen je nach Zielgruppe, eingesetzten Diensten und konkreter Ausgestaltung des Banners unterscheiden können.

2. Verschiedene Consent-Zustände gezielt simulieren

Für eine vollständige Testabdeckung reicht es nicht, ausschliesslich den Zustimmungsfall zu prüfen, da gerade die Fälle Ablehnung und noch keine Entscheidung getroffen aus rechtlicher Sicht die kritischeren Szenarien darstellen: Genau in diesen beiden Zuständen darf kein einziges nicht notwendiges Tracking-Skript laden, weshalb ein Test explizit für jeden der drei relevanten Zustände, Zustimmung, Ablehnung und keine Entscheidung, eine eigene Prüfung durchführen sollte.

In der Praxis lässt sich der jeweilige Consent-Zustand meist direkt über das lokale Speicherobjekt des Browsers oder ein Cookie setzen, das vom Consent-Management-Tool selbst verwaltet wird, statt den kompletten Banner-Klickpfad bei jedem einzelnen Test erneut manuell zu durchlaufen, was den Test sowohl schneller macht als auch präziser auf den tatsächlich zu prüfenden Consent-Zustand fokussiert, unabhängig von möglichen späteren, rein optischen Änderungen am Banner-Design selbst.

test('kein Tracking-Skript lädt ohne Consent-Entscheidung', async ({ page }) => {
  const trackingRequests = [];
  page.on('request', (req) => {
    if (req.url().includes('google-analytics.com') || req.url().includes('facebook.com/tr')) {
      trackingRequests.push(req.url());
    }
  });

  await page.goto('/');
  await page.waitForTimeout(2000);
  expect(trackingRequests).toHaveLength(0);
});

test('Tracking-Skripte laden erst nach aktiver Zustimmung', async ({ page }) => {
  const trackingRequests = [];
  page.on('request', (req) => {
    if (req.url().includes('google-analytics.com')) trackingRequests.push(req.url());
  });

  await page.goto('/');
  expect(trackingRequests).toHaveLength(0);

  await page.click('[data-testid="consent-accept-all"]');
  await page.waitForResponse((res) => res.url().includes('google-analytics.com'));
  expect(trackingRequests.length).toBeGreaterThan(0);
});

3. Ablehnung als eigener, gleichwertiger Testfall

Der Testfall für eine aktive Ablehnung sollte nicht nur prüfen, dass kein Tracking-Skript nach dem Klick auf Ablehnen lädt, sondern zusätzlich, dass ein zuvor durch versehentliches Vorabladen bereits initiiertes Tracking-Skript, sofern die Anwendung ein solches technisch überhaupt zulassen würde, korrekt unterbunden oder nachträglich entfernt wird, da ein bereits gestartetes, aber technisch noch nicht abgeschlossenes Tracking beim späten Ablehnen andernfalls dennoch zum vollständigen Datenabfluss führen könnte.

Ebenso prüfungswürdig ist, dass eine getroffene Ablehnung über einen erneuten Seitenaufruf hinweg tatsächlich bestehen bleibt, also nicht bei jedem neuen Seitenaufruf erneut der vollständige Consent-Banner erscheint, was einerseits aus Nutzersicht störend wäre und andererseits ein Indiz für eine fehlerhafte, nicht persistierte Speicherung der Consent-Entscheidung darstellen würde.

4. Widerruf einer bereits erteilten Zustimmung testen

Die Datenschutz-Grundverordnung verlangt, dass ein Widerruf einer einmal erteilten Zustimmung genauso einfach möglich sein muss wie die ursprüngliche Erteilung, weshalb ein vollständiger Testfall auch prüfen sollte, dass ein nachträglicher Widerruf über die entsprechende Einstellungsseite tatsächlich zum Stoppen bereits aktiver Tracking-Skripte führt, statt lediglich die zukünftige Cookie-Vergabe zu unterbinden, während bereits gesetzte Tracking-Cookies unverändert weiterlaufen.

Dieser Testfall ist in der Praxis technisch etwas aufwendiger, da er nicht nur das Nicht-Laden prüfen muss wie bei der ursprünglichen Ablehnung, sondern das aktive Beenden eines bereits laufenden Zustands, etwa durch Löschen bereits gesetzter Tracking-Cookies oder durch Entladen bereits eingebundener Skripte, weshalb sich hierfür eine gezielte Prüfung des Browser-Cookie-Speichers vor und nach dem Widerruf anbietet, statt sich ausschliesslich auf beobachtete Netzwerkanfragen zu verlassen.

5. Eingebettete Drittanbieter-Inhalte wie Videos und Karten

Neben klassischen Tracking-Skripten enthalten viele Magento-Shops auch eingebettete Drittanbieter-Inhalte wie YouTube-Videos in Produktbeschreibungen oder eine eingebettete Kartenansicht in der Filialsuche, die ebenfalls unter die Consent-Pflicht fallen können, da bereits das blosse Laden des iframes eine Verbindung zum Drittanbieter herstellt und damit potenziell personenbezogene Daten wie die IP-Adresse überträgt.

Für diese Fälle sollte der Test prüfen, dass vor erteilter Zustimmung anstelle des eingebetteten Inhalts ein Platzhalter mit eigenem Zustimmungs-Button erscheint, und dass erst ein gezielter Klick auf diesen Platzhalter, oder alternativ eine zuvor erteilte, generelle Zustimmung, das tatsächliche Nachladen des eingebetteten iframes auslöst, statt den Drittanbieter-Inhalt unabhängig vom Consent-Zustand pauschal zu laden.

6. Zusammenspiel mit dem Tag-Manager in Magento

Viele Magento-Projekte binden Tracking-Skripte nicht direkt, sondern über einen Tag-Manager wie den Google Tag Manager ein, dessen Container selbst wiederum durch Consent-Trigger gesteuert wird, was die eigentliche Prüfung auf den ersten Blick vereinfacht, weil der Consent-Zustand zentral an einer Stelle verwaltet wird, tatsächlich aber eine zusätzliche Fehlerquelle einführt, da eine fehlerhafte Trigger-Konfiguration innerhalb des Tag-Managers selbst, unabhängig vom eigentlichen Anwendungscode, zu einem vorzeitigen Laden führen kann.

Ein E2E-Test sollte deshalb bewusst auf der Netzwerkebene ansetzen und tatsächliche, ausgehende Anfragen an bekannte Tracking-Domains beobachten, statt sich allein auf die korrekte interne Konfiguration des Tag-Managers zu verlassen, da nur die tatsächlich beobachtete Netzwerkanfrage zuverlässig zeigt, was am Ende wirklich beim Nutzer im Browser passiert, unabhängig von der internen Komplexität der dazwischenliegenden Tag-Manager-Konfiguration.

7. Granulare Consent-Kategorien einzeln testen

Ein moderner Consent-Banner unterscheidet in der Regel nicht nur zwischen vollständiger Zustimmung und vollständiger Ablehnung, sondern bietet einzeln aktivierbare Kategorien wie funktional notwendig, Statistik beziehungsweise Analyse, und Marketing an, wobei jede dieser Kategorien unterschiedliche Skripte und Cookies steuert und deshalb aus Testsicht auch einzeln, unabhängig von den anderen Kategorien, geprüft werden sollte.

Ein typischer, oft übersehener Fehler in der praktischen Umsetzung ist, dass ein einzelnes Tracking-Skript fälschlich mit mehreren Kategorien gleichzeitig verknüpft ist, sodass es bereits bei Zustimmung zur funktional notwendigen Kategorie lädt, obwohl es inhaltlich eindeutig der Marketing-Kategorie zuzurechnen wäre. Ein granularer Testfall, der gezielt nur eine einzelne Kategorie aktiviert und die übrigen bewusst deaktiviert lässt, deckt genau diese Art von Fehlzuordnung zuverlässig auf, während ein Test, der immer nur zwischen alles akzeptieren und alles ablehnen unterscheidet, dieselbe Fehlzuordnung vollständig übersehen würde.

8. Consent-Protokollierung und Nachweispflicht testen

Die Datenschutz-Grundverordnung verlangt von einem Verantwortlichen nicht nur die korrekte Einholung der Einwilligung selbst, sondern auch deren Nachweisbarkeit, weshalb ein vollständiges Consent-Management-System jede erteilte oder abgelehnte Entscheidung typischerweise mit Zeitstempel, verwendeter Banner-Version und den jeweils gewählten Kategorien protokollieren muss, um im Zweifelsfall gegenüber einer Aufsichtsbehörde tatsächlich belegen zu können, dass eine gültige Einwilligung tatsächlich vorlag.

Ein ergänzender Testfall sollte deshalb prüfen, dass nach einer Consent-Entscheidung tatsächlich ein entsprechender, korrekt befüllter Protokolleintrag erzeugt wird, etwa durch eine gezielte Prüfung des entsprechenden API-Aufrufs oder Datenbankeintrags, da ein technisch korrekt funktionierender Banner ohne begleitende Protokollierung im Streitfall keinen ausreichenden rechtlichen Nachweis liefert, selbst wenn das sichtbare Nutzerverhalten auf den ersten Blick vollständig korrekt erscheint.

9. Consent-Testfälle im Überblick

Die folgende Tabelle fasst die wichtigsten Consent-Testfälle und ihre jeweilige Prüfungsebene zusammen.

10. Zusammenfassung

11. FAQ: Cookie-Consent-Tests: Das Wichtigste auf einen Blick