ES

← Todos los artículos

Tutoriales

Forzar una variante concreta de test A/B o feature flag para QA

· por JustZix Team

Los tests A/B y los feature flags son geniales para los equipos de producto y un suplicio para QA. Te asignan un grupo una sola vez, al azar, y luego nunca puedes volver a ver la otra variante. Este artículo muestra cómo tomar el control: encontrar el valor que usa el sitio para asignarte un grupo, sobrescribirlo antes de que la página lo lea y fijar una variante por patrón de URL con una regla de JustZix.

Cómo te asignan los sitios a un grupo

Casi todas las herramientas de experimentación del lado del cliente — Optimizely, GrowthBook, LaunchDarkly, Statsig, Split, montajes caseros — funcionan igual. En tu primera visita lanzan un dado, escriben el resultado en algún sitio persistente y leen ese mismo sitio en cada visita posterior para que tu experiencia se mantenga estable. Ese «sitio persistente» es casi siempre una de tres cosas:

Las dos primeras puedes sobrescribirlas directamente. La tercera es más difícil — más sobre eso abajo.

Encontrar la clave de asignación

Abre DevTools y ve a la pestaña Application. Bajo Storage tienes Cookies y Local Storage uno al lado del otro. Recarga la página y busca cualquier cosa que parezca un experimento: claves que contengan ab, exp, variant, flag, bucket, test, feature, o el nombre de un proveedor como optimizely o growthbook.

Si no aparece nada obvio, la decisión llega por la red. Abre la pestaña Network, filtra por Fetch/XHR, recarga y busca una petición a algo como /api/flags, /decide o config.json. El JSON de la respuesta te dice los nombres de las variantes y — lo más importante — bajo qué clave las guarda el SDK.

Sobrescribir localStorage antes de que los scripts lo lean

El momento lo es todo. El SDK de experimentación lee su clave pronto, a menudo antes de DOMContentLoaded. Tu regla JS de JustZix debe ejecutarse antes de esa lectura. Configura la regla para que se ejecute en document_start y escribe el valor de inmediato:

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

Para el enfoque del ID anónimo, elige un ID estable y no aleatorio: la mayoría de los SDK hacen un hash de ese ID para asignar un grupo, así que la misma cadena cae siempre en la misma variante. Prueba varios IDs una vez, anota cuál te da la variante B y reúsalo para siempre.

Sobrescribir una cookie

Las cookies son más sencillas — no hay ningún SDK por medio, solo una cadena. Escríbela en document_start para que los propios scripts de la página vean tu valor:

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

Si la cookie es HttpOnly no puedes tocarla desde JavaScript en absoluto — eso es un flag del lado del servidor, lo vemos a continuación. Puedes confirmarlo en la pestaña Application: las cookies HttpOnly muestran una marca de verificación en esa columna.

Gestionar los flags del lado del servidor

Cuando la variante se decide en el servidor, el HTML que recibes ya es la variante. No hay ningún valor del lado del cliente que cambiar. Tienes dos opciones honestas:

Un override por parámetro de consulta es el camino más limpio. Si tu sitio admite ?ff_override=new-checkout:true, ni siquiera necesitas JavaScript — basta con guardar la URL en marcadores.

Fijar una variante por patrón de URL

La verdadera ventaja con JustZix es el acotado. No quieres que todos los sitios reciban la misma asignación — quieres este entorno de staging fijado a la variante B y aquel sin tocar. Crea una regla con un patrón de URL ajustado:

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

Haz una regla por variante — «Fijar checkout A», «Fijar checkout B», «Fijar control» — y conmútalas desde la barra de acciones. Una pasada de QA por las tres ramas se convierte en tres clics en lugar de tres ventanas de incógnito y mucha suerte.

Verificar que la variante realmente se aplicó

No confíes en que el override funcionó solo porque la página se ve diferente. Confírmalo. La mayoría de los SDK exponen la asignación activa en algún sitio — regístrala desde la Consola de Salida:

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

Combínalo con la ventana de la Consola de Salida para que la asignación sea visible dentro de la pestaña mientras recorres el flujo. Si el SDK reporta la variante que forzaste, tu test es real. Si reporta otra cosa, tu regla se ejecutó demasiado tarde — pásala a document_start.

Errores habituales

Mira también

Deja de depender de ventanas de incógnito y dados afortunados. Instala JustZix, crea una regla por variante y recorre cada rama de cada experimento bajo demanda.

debuggingqajavascriptfeature-flags

Valora este artículo

Sin valoraciones — sé el primero.

Ver también

Pruébalo tú mismo

Instala JustZix y pega cualquier snippet de este artículo. Dos minutos de cero a una regla funcionando en todos tus dispositivos.

Obtener JustZix

Funciones · Cómo funciona · Ejemplos · Casos de uso