Lanzar una prueba rota es peor que no lanzar ninguna. Una prueba rota contamina los datos, confunde a los usuarios y a veces rompe la propia página donde corre. Hacer bien el QA antes del lanzamiento no es opcional.

Este es el proceso que sigo cada vez, independientemente de la herramienta.

Lo primero: ¿la variante se renderiza bien?

Parece obvio. No lo es. La variante puede mostrarse perfectamente en el modo preview de la herramienta y fallar en producción por un problema de timing, un conflicto de CSS, o un selector que ya no existe en esa página.

Siempre hago el QA en una sesión de navegador real, no solo en el panel de preview. Cargo la página, confirmo que la variante aparece y reviso la consola del navegador en busca de errores. Si hay errores que no estaban antes de la prueba, los investigo antes de seguir adelante.

Comprueba cada dispositivo y breakpoint

La mayoría de las pruebas tienen como objetivo escritorio y móvil. La variante puede verse bien a 1440px y estar completamente rota a 375px. Compruebo los dos. Si la prueba es solo para escritorio, verifico igualmente que la exclusión funciona bien en móvil, es decir, que los usuarios de móvil ven el control sin problemas.

También compruebo los navegadores más usados por tu audiencia. Los datos de GA4 te dirán cuáles son. Como mínimo, pruebo Chrome, Safari y Firefox.

Añade las IPs de tu equipo al targeting

Es el paso que más gente se salta cuando va con prisas. En lugar de compartir la variante con links de preview que caducan o que requieren acceso a la herramienta, añado las IPs del equipo a las condiciones de targeting. Así cualquier persona del equipo puede visitar la URL en producción y ver la variante correcta sin afectar a la población general.

Además, significa que el equipo está probando en la página real, no en un entorno sandbox.

Cómo hacerlo en Adobe Target: Ve a tu actividad, haz clic en la audiencia de la variante y añade una nueva regla en la categoría Network. Selecciona IP Address y añade cada IP como condición. Puedes añadir varias direcciones usando el operador OR. Guarda la audiencia y cualquier persona que visite desde esas IPs quedará asignada a la variante automáticamente.

Si tu equipo trabaja desde distintos sitios o usa VPN, pídeles su IP antes de configurar esto. Una forma rápida de comprobarlo es que visiten whatismyip.com.

Cómo hacerlo en Monetate: En Monetate, el targeting se gestiona mediante reglas a nivel de experiencia. Ve a tu experiencia, abre la sección de targeting y añade una condición usando el atributo IP Address. Puedes introducir IPs individuales o rangos CIDR si tu equipo usa un bloque de red fijo. Configura la condición para que coincida con cualquiera de las IPs listadas y guarda.

Una cosa a tener en cuenta con Monetate, asegúrate de que la regla de IP se combina correctamente con el resto de condiciones de targeting. Si usas lógica AND entre reglas, la condición de IP tiene que cumplirse junto con todas las demás. Si quieres que los miembros del equipo puedan saltarse otras condiciones de targeting, considera crear una experiencia de QA independiente que solo se active para las IPs autorizadas.

Verifica que los eventos de analítica están disparando

La prueba puede verse perfecta visualmente y aun así recoger datos incorrectos. Abro la pestaña de red del navegador, o uso el DebugView de GA4, y confirmo que el evento de exposición al experimento se dispara cuando se ve la variante, y que los eventos de interacción ligados a los objetivos de la prueba se activan correctamente.

Si usas eventos personalizados, comprueba que el nombre del evento, los parámetros y los valores coinciden exactamente con lo que está configurado en GA4. Un error tipográfico en el nombre de un evento significa que pasarás una semana analizando datos que nunca existieron.

Prueba también el control

Es fácil olvidarlo. El control debe verse exactamente igual que la página antes de la prueba. Si estás inyectando CSS o JavaScript a nivel de experimento, puede afectar al control aunque no haya cambios visuales previstos. Siempre cargo una sesión asignada al control y verifico que nada ha cambiado.

Comprueba el flicker

El flicker ocurre cuando la página carga un instante en su estado por defecto antes de que la variante se renderice. Los usuarios ven un destello del contenido original antes de que cambie. Es una mala experiencia y puede sesgar los resultados, porque los usuarios que lo notan pueden comportarse de forma distinta.

Para detectar el flicker, limita la conexión en Chrome DevTools a Slow 3G y recarga la página. Si puedes ver la versión original aunque sea una fracción de segundo antes de que aparezca la variante, la implementación necesita ajustarse. El fix suele ser mover el script del experimento más arriba en la página o usar correctamente el snippet anti-flicker de la herramienta.

Una segunda opinión siempre

Tengo la costumbre de pedirle a otra persona que haga el QA antes del lanzamiento, alguien que no haya construido la prueba. Va a hacer clic en cosas en las que tú no pensaste. Lo va a probar en un dispositivo que tú no usaste. Va a encontrar lo que tú eras demasiado cercano para ver.

Con el whitelisting de IPs ya configurado, esto es sencillo. Le mandas la URL en producción, te confirma lo que ve y listo.

Último repaso antes de activar

• La variante se renderiza correctamente en producción

• No hay errores en consola introducidos por la prueba

• Verificado en móvil y escritorio

• Los eventos de analítica se disparan con los valores correctos

• El control está intacto

• No hay flicker visible en conexiones lentas

• Al menos otra persona ha confirmado la variante desde su lado

Son unos quince minutos. Me ha salvado de lanzar pruebas rotas más veces de las que me gustaría contar.