← Alle Beiträge

Anleitungen

Eine bestimmte A/B-Test- oder Feature-Flag-Variante fürs QA erzwingen

16 Mai 2026 · von JustZix Team

A/B-Tests und Feature-Flags sind großartig für Produktteams und ein Elend für QA. Du wirst einmal, zufällig, in einen Bucket gesteckt — und siehst die andere Variante danach nie wieder. Dieser Artikel zeigt, wie du die Kontrolle übernimmst: Finde den Wert, mit dem die Seite dich einordnet, überschreibe ihn, bevor die Seite ihn liest, und pinne eine Variante pro URL-Muster mit einer JustZix-Regel.

Wie Seiten dich einordnen

Fast jedes clientseitige Experimentier-Tool — Optimizely, GrowthBook, LaunchDarkly, Statsig, Split, Eigenbau-Lösungen — funktioniert gleich. Bei deinem ersten Besuch würfelt es, schreibt das Ergebnis irgendwo dauerhaft hin und liest dieselbe Stelle bei jedem späteren Besuch, damit deine Erfahrung stabil bleibt. Dieses „irgendwo dauerhaft" ist fast immer eines von drei Dingen:

• Ein Cookie (z. B. ab_variant=B oder eine anonyme Nutzer-ID, die in einen Bucket gehasht wird).
• Ein localStorage-Schlüssel (üblich bei GrowthBook- und Statsig-SDKs).
• Eine serverseitige Entscheidung, fest ins HTML eingebacken oder von einem API-Aufruf zurückgegeben.

Die ersten beiden kannst du direkt überschreiben. Das dritte ist schwieriger — mehr dazu unten.

Den Bucketing-Schlüssel finden

Öffne die DevTools und gehe zum Tab Application. Unter Storage hast du Cookies und Local Storage nebeneinander. Lade die Seite neu und such nach allem, was nach einem Experiment aussieht: Schlüssel mit ab, exp, variant, flag, bucket, test, feature oder einem Anbieternamen wie optimizely oder growthbook.

Falls nichts Offensichtliches auftaucht, kommt die Entscheidung übers Netzwerk. Öffne den Tab Network, filtere auf Fetch/XHR, lade neu und such nach einer Anfrage an etwas wie /api/flags, /decide oder config.json. Das Antwort-JSON verrät dir die Variantennamen und — entscheidend — unter welchem Schlüssel das SDK sie speichert.

localStorage überschreiben, bevor Skripte es lesen

Timing ist alles. Das Experimentier-SDK liest seinen Schlüssel früh, oft vor DOMContentLoaded. Deine JustZix-JS-Regel muss vor diesem Lesen laufen. Stelle die Regel auf document_start und schreibe den Wert sofort:

// Pin the GrowthBook-style variant before the SDK initialises
const KEY = 'gb_anonymous_id';      // the bucketing key you found
const FORCED = 'qa-pinned-variant-b';

// Overwrite whatever value the SDK would have rolled
localStorage.setItem(KEY, FORCED);

// Some SDKs cache a whole decision object — pin that too
localStorage.setItem('growthbook_features', JSON.stringify({
  'new-checkout': { defaultValue: true },
  'pricing-table-v2': { defaultValue: 'variant-b' }
}));

Wähle für den Ansatz mit anonymer ID eine stabile, nicht-zufällige ID: Die meisten SDKs hashen diese ID in einen Bucket, also landet derselbe String immer in derselben Variante. Probiere einmal ein paar IDs durch, merk dir, welche dir Variante B liefert, und nutze sie für immer.

Ein Cookie überschreiben

Cookies sind einfacher — kein SDK steht im Weg, nur ein String. Schreib ihn bei document_start, damit die seiteneigenen Skripte deinen Wert sehen:

// Force the experiment cookie for this domain
function setCookie(name, value) {
  document.cookie =
    name + '=' + value + '; path=/; max-age=31536000; SameSite=Lax';
}

setCookie('ab_variant', 'B');
setCookie('feature_new_nav', 'on');

Ist das Cookie HttpOnly, kannst du es aus JavaScript überhaupt nicht anfassen — das ist ein serverseitiges Flag, dazu gleich mehr. Bestätigen kannst du das im Tab Application: HttpOnly-Cookies zeigen ein Häkchen in dieser Spalte.

Serverseitige Flags behandeln

Wird die Variante auf dem Server entschieden, ist das HTML, das du erhältst, bereits die Variante. Es gibt keinen clientseitigen Wert zum Umlegen. Du hast zwei ehrliche Optionen:

• Schicke einen Hinweis, den der Server beachtet. Viele Setups lesen ein nicht-HttpOnly-Override-Cookie wie x-force-variant oder einen Query-Parameter ?ab_force=B ganz gezielt, damit QA Zweige testen kann. Frag dein Team — diese Overrides existieren meist und sind nur undokumentiert.
• Skinne die Variante, die du hast, um. Wenn du das echte Markup von Variante B nicht bekommst, kannst du den sichtbaren Unterschied manchmal mit einer CSS-Regel für Screenshots annähern — aber das ist ein Mockup, kein echter Test. Nutze es nur für Design-Reviews, nie für funktionales QA.

Ein Override per Query-Parameter ist der sauberste Weg. Unterstützt deine Seite ?ff_override=new-checkout:true, brauchst du nicht einmal JavaScript — leg dir einfach die URL als Lesezeichen an.

Eine Variante pro URL-Muster pinnen

Der echte Gewinn mit JustZix ist das Scoping. Du willst nicht jede Seite gleich einordnen — du willst diese Staging-Umgebung auf Variante B gepinnt und jene in Ruhe gelassen. Erstelle eine Regel mit einem engen URL-Muster:

URL pattern:  https://staging.example.com/*
JS (document_start):
  localStorage.setItem('exp_checkout', 'variant-b');
  document.cookie = 'ab_force=B; path=/';

Mach eine Regel pro Variante — „Checkout A pinnen", „Checkout B pinnen", „Kontrolle pinnen" — und schalte sie aus der Aktionsleiste um. Ein QA-Durchlauf durch alle drei Zweige wird zu drei Klicks statt drei Inkognito-Fenstern und viel Glück.

Prüfen, ob die Variante wirklich gegriffen hat

Vertraue nicht darauf, dass das Override funktioniert hat, nur weil die Seite anders aussieht. Bestätige es. Die meisten SDKs legen die aktive Zuweisung irgendwo offen — logge sie aus der Output Console:

// Read back what the SDK decided, after it initialised
window.addEventListener('load', () => {
  // GrowthBook example
  if (window.growthbook) {
    console.log('Active features:', window.growthbook.getFeatures());
  }
  // Generic: dump every storage key for the audit trail
  console.log('Forced storage:', { ...localStorage });
});

Kombiniere das mit dem Output-Console-Fenster, damit die Zuweisung im Tab sichtbar ist, während du dich durch den Flow klickst. Meldet das SDK die Variante, die du erzwungen hast, ist dein Test echt. Meldet es etwas anderes, lief deine Regel zu spät — schieb sie auf document_start.

Häufige Stolperfallen

• Zu spät laufen. Eine Regel bei document_idle verliert das Rennen. Das SDK hat seinen Schlüssel schon gelesen. Nutze für Bucketing-Overrides immer document_start.
• Die Server-Hälfte vergessen. Du hast die Client-Variante gepinnt, aber der Server rendert weiter die Kontrolle. Such nach einem Override-Cookie oder -Parameter.
• Analytics verschmutzen. Erzwungene Sitzungen verzerren Experimentergebnisse. Nutze eine Staging-Umgebung oder bitte dein Datenteam, QA-Traffic auszuschließen.
• Veraltete Caches. Manche SDKs cachen die Entscheidung stundenlang. Lösche zuerst den betreffenden Storage-Schlüssel, dann setze deinen erzwungenen Wert.

Siehe auch

• API-Antworten durch Abfangen von fetch mocken — fälsche den Flag-Endpunkt statt des Storage-Schlüssels.
• Zeitbasierte Regeln — plane, welche Variante nach Tag oder Stunde gepinnt ist.
• JustZix-Anwendungsfälle — mehr QA- und Debugging-Workflows.

Hör auf, dich auf Inkognito-Fenster und glückliche Würfelwürfe zu verlassen. Installiere JustZix, baue eine Regel pro Variante und durchlaufe auf Abruf jeden Zweig jedes Experiments.