Un QA previo al lanzamiento que sí encuentra errores

Hay dos clases de QA previo al lanzamiento. Una produce un documento que hace sentir preparados a todos. La otra encuentra la cosa que habría costado dinero el martes. De lejos se parecen, y la diferencia es casi por completo qué entradas eliges.

Las revisiones de abajo se ganaron su lugar: cada una tiene un fallo específico que existe para atrapar, y cada una la puede correr alguien que no sea el desarrollador. Es una lista de trabajo con su razonamiento pegado, porque una lista sin razonamiento se salta la primera vez que se mueve una fecha.

Las revisiones que solo parecen exhaustivas

Vale la pena nombrarlas primero, porque son las que se comen el presupuesto de QA.

La matriz de navegadores. Abrir la home en cinco navegadores de escritorio encuentra sobre todo la misma página cinco veces. No encuentra bugs de lógica, que son los que rompen pedidos. Un dispositivo real en el checkout vale más que cuatro navegadores de escritorio en la home.

Hacer clic en todos los enlaces. Un crawler hace esto en noventa segundos y lo hace mejor. La atención humana debería ir a donde un crawler no llega: estado, combinación y secuencia.

La captura del puntaje de rendimiento. Un número tomado una vez, con carrito vacío, en una conexión rápida y desde una región cercana. No está mal; simplemente no es evidencia de nada que vaya a experimentar un cliente. El trabajo real de velocidad es una disciplina aparte, no una línea en una pasada de QA.

El camino feliz. Un producto, cantidad uno, sin descuento, a precio completo, en stock, dirección nacional, tarjeta de crédito. Es el único camino que alguien prueba y el único que nunca se rompe, porque es contra el que todos construyeron.

El carrito, y todo lo que pasa en la cantidad

La cantidad es donde viven los bugs más caros, porque la aritmética por unidad y por línea se ven idénticas cuando la cantidad es uno. Cada uno de estos tiene un modo de fallo real detrás.

• Agrega el mismo producto dos veces en dos visitas. ¿Se fusiona en una línea de cantidad dos o crea una segunda línea? Ambos comportamientos son defendibles; solo uno es el que asume la lógica de precios.
• Lleva una línea a once. Cualquier cargo, recargo, regla de bundle o Cart Transform escrito pensando en una unidad va a estar mal aquí, y va a estar mal por un factor y no por un redondeo. Si hay una Function involucrada, este es el caso que sus pruebas unitarias ya deberían cubrir, y esto lo confirma.
• Pon una cantidad por encima del inventario disponible. Revisa qué dice el carrito, qué dice el checkout, y si dicen lo mismo. Que esas dos superficies no coincidan es un defecto común y silencioso.
• Pon una cantidad en cero. La línea debería irse. Revisa si algo aguas abajo — una regla de regalo, un umbral de envío, una barra de progreso — sigue creyendo que está ahí.
• Mezcla tipos de producto en un carrito. Una tarjeta de regalo, un artículo de suscripción, un producto digital y uno físico juntos. Los cargos y descuentos escritos para bienes físicos suelen tener opiniones sobre las tarjetas de regalo que nadie enunció.
• Cruza un umbral de envío y luego regresa. Agrega hasta llegar a envío gratis, y después quita. Los umbrales que solo corren en una dirección son un clásico.
• Recarga el carrito y ábrelo en una segunda pestaña. El estado de carrito que vive en JavaScript en vez de en el objeto cart se separa justo aquí.

Descuentos, y las combinaciones que nadie escribió

Los bugs de descuentos son los que descubren los clientes en un foro. La regla es simple: cada mecanismo de descuento debe probarse contra todos los demás, y el resultado esperado se escribe antes de la prueba, no se decide mirando la salida.

• Automático más código. ¿Se acumulan? ¿Deberían? El modelo de combinación de Shopify es explícito: esta configuración o la pusiste a propósito o la heredaste.
• Descuento de producto más de pedido más de envío. Los tres a la vez, en un carrito que además cruza un umbral de envío gratis.
• Un descuento en un carrito con un artículo excluido. La exclusión debe aplicar a esa línea y a nada más. Revisa el total, no solo el badge.
• Un descuento en cantidad, otra vez. "Veinte por ciento" sobre una línea de siete es donde la lógica por línea se delata.
• Un código expirado y un código de otro market. El mensaje de error importa tanto como el error.
• Una tarjeta de regalo más un descuento. El orden de aplicación cambia el total, y conviene saber cuál orden te está tocando.

Si la tienda tiene extensiones de UI de checkout en juego, cada una de estas debería repetirse con la extensión renderizando: lo que ve el comprador en el checkout y lo que hizo la lógica de precios son dos sistemas separados que pueden no coincidir.

El mapa de redirects, verificado como lista

En una replataformación o una reconstrucción, esta es la revisión con el valor monetario más claro, y es la que más seguido se reemplaza por una sensación.

Toma la lista real de URLs de la tienda vieja — no el sitemap nuevo — y ponla en una columna. Cada producto, colección, página, artículo de blog, y cualquier URL de colección filtrada que se haya indexado. Agrega los descontinuados: siguen recibiendo tráfico y clics de anuncios. Después pide cada una contra la tienda nueva y anota el código de estado y el destino final.

Lo que buscas no son solo los 404. Un 301 a la home es técnicamente un redirect y prácticamente una venta perdida: le dice al visitante que su producto no existe sin decírselo. Las cadenas de dos y tres redirects son el otro hallazgo, residuo de una migración anterior que nadie limpió. Va con la implementación de SEO, y tiene que estar terminado antes del lanzamiento.

Datos estructurados, revisados por plantilla y no por página

Los errores de datos estructurados casi siempre son errores de plantilla, así que revisa una página de cada tipo y no muchas de un tipo: un producto simple, uno con variantes, uno agotado, una colección, un artículo y la página de búsqueda.

Lo que se rompe en concreto: precio y moneda separándose de lo que muestra la página, disponibilidad diciendo todavía "en stock" en un producto agotado, marcado de reseñas que quedó en el tema sin reseñas detrás, y marcado duplicado porque lo emiten el tema y una app instalada a la vez. Ese último es lo bastante común tras una auditoría de apps como para revisarlo a propósito.

Checkout, en un dispositivo real, en una red real

Esta es la revisión que más se salta y la que más encuentra. No un emulador: un teléfono de verdad, con datos móviles, y —porque un rechazo exige modo de prueba o la Bogus Gateway— una segunda pasada contra la configuración de pago real para las rutas que deben funcionar.

• Completa una compra de punta a punta, incluyendo los botones de wallet y no solo el formulario de tarjeta.
• Escribe una dirección que a la validación de direcciones no le guste, y mira si el comprador puede continuar.
• Elige cada tarifa de envío, incluidas las que una personalización de tarifas debería ocultar o renombrar.
• Abandona en el paso de pago, regresa por el correo de recuperación, y confirma que el carrito está intacto.
• Revisa la página de confirmación, el correo y la vista de la cuenta del cliente. Las propiedades de línea personalizadas y la salida de Cart Transform suelen verse bien en una de las tres y mal en las otras.
• Haz un pedido que dispare cada notificación que la tienda usa, y léelas. Los campos de combinación que renderizan en blanco son un clásico de la semana de lanzamiento.

Vacío, error, y los estados que nadie diseña

Cada uno de estos lo va a ver una persona real en la primera semana, y ninguno está en el archivo de diseño.

• Carrito vacío. ¿Ofrece una salida, o es un callejón sin salida con un encabezado?
• Búsqueda vacía. Una búsqueda de un término sin resultados, y una búsqueda mal escrita de un producto que sí vendes.
• Una colección filtrada a nada. Las combinaciones de filtros que devuelven cero productos deben decirlo y ofrecer deshacer el último filtro.
• Una ficha de producto agotado, y un producto con una variante agotada. La segunda es donde el selector de variantes o ayuda o miente.
• 404. Se va a golpear constantemente durante la cola de redirects: debería llevar búsqueda y navegación en vez de una disculpa.
• Un pago rechazado. Usa una tarjeta de prueba que se rechace y lee qué se le dice al comprador.
• Contenido largo. Un producto con un título de cuarenta palabras, una dirección larguísima, un carrito de quince líneas. Los layouts se rompen en los extremos, y los extremos existen en todos los catálogos.

El orden en que conviene correrlo

Datos primero, después lógica, después presentación. Redirects y datos estructurados tienen forma de lista y pueden empezar antes de que el tema esté terminado. Carrito, cantidad y descuentos van después, porque un hallazgo ahí puede cambiar código. El checkout en dispositivo y los estados vacíos van al final, cuando lo que pruebas es lo que se va a publicar.

La regla que hace que todo esto se sostenga: cada fallo encontrado se escribe con la entrada que lo causó, no con una descripción de cómo se veía. "Cantidad once, una tarjeta de regalo en el carrito, descuento automático activo" es un reporte que alguien reproduce en treinta segundos. "El total del carrito se veía raro" es una conversación.