← Wszystkie wpisy

Poradniki

Wymuś konkretny wariant testu A/B lub feature flagi na potrzeby QA

16 maja 2026 · autor JustZix Team

Testy A/B i feature flagi są świetne dla zespołów produktowych i męczące dla QA. Trafiasz do kubełka raz, losowo, i potem nigdy więcej nie zobaczysz drugiego wariantu. Ten artykuł pokazuje, jak przejąć kontrolę: znaleźć wartość, której strona używa do przypisania kubełka, nadpisać ją zanim strona ją odczyta i przypiąć wariant per wzorzec URL za pomocą reguły JustZix.

Jak strony przypisują Cię do kubełka

Niemal każde narzędzie do eksperymentów po stronie klienta — Optimizely, GrowthBook, LaunchDarkly, Statsig, Split, rozwiązania własne — działa tak samo. Przy pierwszej wizycie rzuca kostką, zapisuje wynik gdzieś trwale i odczytuje to samo miejsce przy każdej kolejnej wizycie, aby Twoje doświadczenie pozostało stabilne. To „gdzieś trwale” to prawie zawsze jedna z trzech rzeczy:

• Cookie (np. ab_variant=B albo anonimowy identyfikator użytkownika, który po zahaszowaniu trafia do kubełka).
• Klucz w localStorage (częste w SDK GrowthBook i Statsig).
• Decyzja po stronie serwera wkomponowana w HTML lub zwracana przez wywołanie API.

Dwie pierwsze możesz nadpisać bezpośrednio. Trzecia jest trudniejsza — więcej o tym poniżej.

Znajdowanie klucza przypisania do kubełka

Otwórz DevTools i przejdź do zakładki Application. W sekcji Storage masz obok siebie Cookies i Local Storage. Przeładuj stronę i poszukaj czegokolwiek, co wygląda jak eksperyment: kluczy zawierających ab, exp, variant, flag, bucket, test, feature albo nazwę dostawcy w stylu optimizely czy growthbook.

Jeśli nic oczywistego się nie pojawia, decyzja przychodzi przez sieć. Otwórz zakładkę Network, przefiltruj do Fetch/XHR, przeładuj i poszukaj żądania do czegoś w stylu /api/flags, /decide lub config.json. JSON odpowiedzi mówi Ci, jakie są nazwy wariantów i — co najważniejsze — pod jakim kluczem SDK je przechowuje.

Nadpisywanie localStorage zanim skrypty go odczytają

Liczy się czas. SDK do eksperymentów odczytuje swój klucz wcześnie, często przed DOMContentLoaded. Twoja reguła JS w JustZix musi uruchomić się przed tym odczytem. Ustaw regułę tak, aby uruchamiała się na document_start, i zapisz wartość natychmiast:

// 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' }
}));

Przy podejściu z anonimowym identyfikatorem wybierz stabilny, nielosowy ID: większość SDK haszuje ten ID do kubełka, więc ten sam ciąg znaków zawsze trafia do tego samego wariantu. Przejdź raz przez kilka identyfikatorów, zanotuj, który daje wariant B, i używaj go już zawsze.

Nadpisywanie cookie

Cookies są prostsze — nie ma żadnego SDK po drodze, tylko ciąg znaków. Zapisz go na document_start, aby skrypty strony zobaczyły Twoją wartość:

// 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');

Jeśli cookie jest oznaczone jako HttpOnly, w ogóle nie dotkniesz go z poziomu JavaScriptu — to flaga po stronie serwera, omówiona dalej. Możesz to potwierdzić w zakładce Application: cookies HttpOnly mają zaznaczone pole w tej kolumnie.

Obsługa flag po stronie serwera

Gdy wariant jest decydowany na serwerze, HTML, który otrzymujesz, jest już wariantem. Nie ma żadnej wartości po stronie klienta do przełączenia. Masz dwie uczciwe opcje:

• Wyślij wskazówkę, którą serwer respektuje. Wiele konfiguracji odczytuje cookie nadpisujące bez flagi HttpOnly, w stylu x-force-variant, albo parametr zapytania ?ab_force=B właśnie po to, aby QA mogło testować gałęzie. Zapytaj swój zespół — takie nadpisania zwykle istnieją, po prostu są nieudokumentowane.
• Przemaluj wariant, który masz. Jeśli nie możesz uzyskać prawdziwego markupu wariantu B, czasem da się przybliżyć widoczną różnicę regułą CSS na potrzeby zrzutów ekranu — ale to imitacja, nie prawdziwy test. Używaj jej wyłącznie do przeglądu projektu, nigdy do funkcjonalnego QA.

Nadpisanie przez parametr zapytania to najczystsza droga. Jeśli Twoja strona obsługuje ?ff_override=new-checkout:true, nie potrzebujesz nawet JavaScriptu — wystarczy dodać URL do zakładek.

Przypinanie wariantu per wzorzec URL

Prawdziwa zaleta JustZix to ograniczanie zasięgu. Nie chcesz, aby każda strona była przypisana do kubełka tak samo — chcesz, aby to środowisko staging było przypięte do wariantu B, a tamto zostawione w spokoju. Utwórz regułę z wąskim wzorcem URL:

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

Zrób jedną regułę na wariant — „Przypnij checkout A”, „Przypnij checkout B”, „Przypnij kontrolę” — i przełączaj je z paska akcji. Przejście QA przez wszystkie trzy gałęzie staje się trzema kliknięciami zamiast trzech okien incognito i sporej dawki szczęścia.

Sprawdzanie, czy wariant faktycznie zadziałał

Nie ufaj, że nadpisanie zadziałało tylko dlatego, że strona wygląda inaczej. Potwierdź to. Większość SDK gdzieś udostępnia aktywne przypisanie — zaloguj je z 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 });
});

Połącz to z oknem Output Console, aby przypisanie było widoczne w karcie, gdy klikasz przez przepływ. Jeśli SDK raportuje wariant, który wymusiłeś, Twój test jest prawdziwy. Jeśli raportuje coś innego, Twoja reguła uruchomiła się za późno — przesuń ją na document_start.

Częste pułapki

• Uruchamianie za późno. Reguła na document_idle przegrywa wyścig. SDK już odczytało swój klucz. Do nadpisań kubełka zawsze używaj document_start.
• Zapominanie o połowie serwerowej. Przypiąłeś wariant kliencki, ale serwer wciąż renderuje kontrolę. Poszukaj cookie lub parametru nadpisującego.
• Zanieczyszczanie analityki. Wymuszone sesje zniekształcają wyniki eksperymentów. Używaj środowiska staging albo poproś zespół danych o wykluczenie ruchu QA.
• Nieaktualne cache'e. Niektóre SDK buforują decyzję na wiele godzin. Najpierw wyczyść odpowiedni klucz storage, potem ustaw swoją wymuszoną wartość.

Zobacz też

• Mockuj odpowiedzi API, przechwytując fetch — podrabiaj endpoint flagi zamiast klucza storage.
• Reguły zależne od czasu — zaplanuj, który wariant jest przypięty według dnia lub godziny.
• Zastosowania JustZix — więcej przepływów QA i debugowania.

Przestań polegać na oknach incognito i szczęśliwych rzutach kostką. Zainstaluj JustZix, zbuduj jedną regułę na wariant i przerabiaj każdą gałąź każdego eksperymentu na żądanie.