Checklist de QA visual: qué verificar antes de cada release

Lanzar un release sin QA visual es una apuesta. Los tests funcionales confirman que las funcionalidades operan, pero no confirman que la interfaz se vea correcta. Un botón puede pasar cada test de integración y aun así solaparse con un campo de formulario en Safari móvil. Un encabezado puede renderizarse perfectamente en inglés y desbordar su contenedor al traducirse al alemán.

Esta checklist cubre las verificaciones visuales que cada equipo web debería ejecutar antes de que un release llegue a producción. Úsela tal cual o adáptela a su stack técnico y audiencia específicos.

Por qué es importante una checklist visual

Los errores visuales son particularmente dañinos porque son inmediatamente visibles para los usuarios. Un elemento mal alineado o una maquetación rota erosiona la confianza de formas que una respuesta API lenta no puede. Sin embargo, la QA visual es a menudo la parte más improvisada del proceso de release — realizada de manera inconsistente, por diferentes personas, sin criterios compartidos.

Una checklist escrita resuelve esto haciendo que la QA visual sea repetible y medible. Todos en el equipo saben lo que significa «verificado visualmente», y ninguna categoría de verificación se omite porque alguien la olvidó.

Maquetación y espaciado

Los problemas de maquetación son las regresiones visuales más comunes. Verifíquelos sistemáticamente:

La estructura de la página está intacta — el encabezado, contenido principal, barra lateral (si existe) y pie de página se renderizan en el orden correcto con el espaciado esperado.
Las maquetaciones grid y flexbox se redistribuyen correctamente — verifique en anchos de escritorio, tableta y móvil. Busque redistribución inesperada de columnas o elementos desbordando sus contenedores.
El espaciado entre secciones es consistente — los márgenes y padding coinciden con la especificación de diseño. Vigile secciones demasiado juntas o demasiado separadas.
No hay elementos superpuestos — compruebe que los elementos posicionados absolutamente (tooltips, dropdowns, modales) no solapen contenido ni se extiendan más allá del viewport.
Los elementos sticky y fixed se comportan correctamente — los encabezados sticky y pies de página fixed deben permanecer en posición durante el desplazamiento sin cubrir el contenido detrás de ellos.

Para la verificación automatizada de maquetación en todos los breakpoints, consulte nuestra guía sobre workflows de tests cross-browser.

Tipografía y contenido

Los problemas de renderizado de texto son sutiles pero afectan la legibilidad y el profesionalismo:

Los encabezados siguen la jerarquía correcta — los tamaños y pesos de H1, H2, H3 coinciden con el design system.
El texto del cuerpo es legible — el tamaño de fuente, la altura de línea y el contraste cumplen los estándares de accesibilidad. Pruebe con contenido real, no con texto de relleno.
No hay truncamiento ni desbordamiento de texto — los encabezados largos, las cadenas traducidas y el contenido dinámico caben en sus contenedores. Verifique especialmente con idiomas más largos como el alemán.
Los enlaces son visualmente distinguibles — el subrayado, el color u otro estilo hace que los enlaces sean identificables sin depender únicamente del color.
Los bloques de código y texto preformateado se renderizan correctamente — las fuentes monoespaciadas cargan, el resaltado de sintaxis funciona y aparece desplazamiento horizontal para líneas largas.
Las listas se renderizan con los marcadores correctos — las listas ordenadas muestran números, las no ordenadas muestran viñetas, y la anidación es visualmente clara.

Comportamiento responsive

Los errores responsive representan una proporción desproporcionada de los problemas visuales reportados por usuarios:

Maquetación móvil (ancho 375 px) — verifique toda la página al ancho móvil típico. La navegación se colapsa al menú hamburguesa, las imágenes escalan y el contenido se apila verticalmente.
Maquetación tableta (ancho 768 px) — aquí es donde se esconden la mayoría de los errores responsive. Las maquetaciones de dos columnas deben transicionar limpiamente, y los objetivos táctiles deben tener un tamaño adecuado.
Maquetación escritorio (ancho 1440 px) — la experiencia de escritorio principal. Las maquetaciones multicolumna se muestran correctamente y se respetan los anchos máximos de contenido.
Escritorio amplio (ancho 1920 px+) — el contenido no debería estirarse para llenar pantallas ultra anchas. Compruebe que los anchos máximos y el centrado funcionan correctamente.
Cambios de orientación — en móvil y tableta, cambiar entre retrato y paisaje no debería romper la maquetación.
Comportamiento del zoom — el zoom del navegador al 150 % y 200 % no debería causar solapamiento o contenido oculto.

Renderizado cross-browser

Los diferentes motores de navegador interpretan el CSS de manera diferente. Verifique al menos estas combinaciones:

Chrome escritorio — su renderizado de referencia. La mayoría de los usuarios verán esta versión.
Firefox escritorio — detecta problemas específicos de Gecko con gap en flexbox, métricas de fuentes y propiedades personalizadas.
Safari escritorio — WebKit tiene un comportamiento único para backdrop-filter, position-sticky y flex-wrap.
Safari móvil (iOS) — todos los navegadores iOS usan WebKit. El manejo del viewport, los insets de zona segura y el comportamiento de desplazamiento difieren del escritorio.
Chrome móvil (Android) — verifique los objetivos táctiles, el comportamiento del meta viewport y el estilo específico para móvil.

No necesita verificar cada navegador para cada página. Priorice por datos de tráfico: cubra las combinaciones que representan el 90 % de su audiencia. Consulte nuestro guía de tests de regresión visual para más información sobre la construcción de una matriz de navegadores.

Estados interactivos

Los elementos interactivos tienen múltiples estados visuales. Cada uno necesita verificación:

Botones — los estados por defecto, hover, focus, activo, deshabilitado y de carga se renderizan todos correctamente y son visualmente distintos.
Campos de formulario — estados vacío, enfocado, rellenado, error y deshabilitado. Compruebe que los mensajes de error aparecen en la posición correcta y no desplazan la maquetación.
Navegación — indicador de página activa, efectos hover en enlaces, menús desplegables abriéndose y cerrándose en la posición correcta.
Modales y diálogos — se abren suavemente, se centran correctamente en todos los tamaños de pantalla y muestran un fondo visible. El botón de cerrar es accesible.
Tooltips y popovers — aparecen en la posición correcta respecto a su disparador. No se recortan por contenedores overflow-hidden o el borde del viewport.
Estados de carga — las pantallas skeleton, spinners y barras de progreso se muestran correctamente durante la carga de datos.

Imágenes y medios

Los medios visuales requieren su propio conjunto de verificaciones:

Las imágenes cargan y se muestran — sin iconos de imagen rota. Todas las imágenes tienen texto alt apropiado para accesibilidad.
Las imágenes están correctamente dimensionadas — sin distorsión ni recorte inesperado. Las proporciones se mantienen.
Las imágenes responsive sirven los tamaños apropiados — los dispositivos móviles no descargan imágenes de tamaño escritorio.
Las incrustaciones de vídeo funcionan — los botones de reproducción se muestran, las proporciones son correctas y las incrustaciones no desbordan sus contenedores.
Los iconos se renderizan correctamente — los iconos SVG se muestran al tamaño y color correctos. Las fuentes de iconos cargan sin mostrar caracteres de respaldo.

Accesibilidad y color

La QA visual y la accesibilidad se solapan significativamente:

El contraste de color cumple WCAG AA — el texto y los elementos interactivos tienen suficiente contraste con sus fondos. Verifique tanto el tema claro como el oscuro si aplica.
Los indicadores de focus son visibles — la navegación por teclado debe mostrar un anillo de focus claro en todos los elementos interactivos.
El modo oscuro se renderiza correctamente — si su aplicación soporta modo oscuro, verifique que todos los componentes, imágenes y textos sean legibles en ambos temas.
No se transmite información solo por color — los estados de error, indicadores de estado y campos obligatorios usan iconos o texto además del color.

Verificaciones visuales relacionadas con el rendimiento

Los problemas de rendimiento pueden manifestarse como problemas visuales:

Sin desplazamiento de maquetación durante la carga — el contenido no salta mientras se cargan fuentes, imágenes o scripts. Esto se mide por el Cumulative Layout Shift (CLS).
Las fuentes web se cargan antes del renderizado — sin flash de texto sin estilo (FOUT) ni texto invisible (FOIT) durante la carga de la página.
El contenido above-the-fold se renderiza rápido — la parte visible de la página debería aparecer en 1–2 segundos con buena conexión.

Flujo de trabajo de verificación pre-release

Use este flujo de trabajo para ejecutar la checklist de manera consistente:

Despliegue en staging — verifique contra un entorno que replica la producción lo más fielmente posible.
Ejecute tests de screenshots automatizados — capture baselines en su matriz de navegadores y dispositivos. Consulte nuestro guía de automatización CI/CD para instrucciones de configuración.
Revise los diffs automatizados — clasifique cada diff como intencional, regresión o ruido.
Realice verificaciones manuales puntuales — los tests automatizados cubren el renderizado estático. Verifique manualmente los estados interactivos, animaciones y casos extremos.
Documente los resultados — registre qué verificaciones pasaron, cuáles fallaron y qué se corrigió. Esto crea una pista de auditoría para futuros releases.
Apruebe o bloquee — si todas las verificaciones pasan, apruebe el release. Si persisten errores visuales críticos, bloquee hasta que se resuelvan.

Adaptar la checklist a su equipo

Esta checklist es exhaustiva por diseño. Para su equipo, personalícela en función de:

Su stack técnico — si no soporta modo oscuro, elimine esas verificaciones. Si usa un design system, añada verificaciones a nivel de componentes.
Su audiencia — si el 95 % de su tráfico viene de Chrome, reduzca el alcance cross-browser y aumente los tests móviles.
Su tolerancia al riesgo — las aplicaciones críticas para los ingresos necesitan verificaciones más estrictas. Las herramientas internas pueden usar un proceso más ligero.

La clave es la consistencia. Una checklist más corta que se ejecuta en cada release tiene más valor que una exhaustiva que se salta bajo presión de plazos.

Continúe con ScanU

Los tests de screenshots automatizados gestionan las partes más laboriosas de esta checklist: verificación de maquetación, renderizado cross-browser y verificaciones de breakpoints responsive. ScanU captura screenshots en todos los navegadores y dispositivos para que su equipo pueda concentrarse en los estados interactivos y casos extremos. Explore las opciones de planes en Pricing, conozca la plataforma en Features y consulte las respuestas a preguntas frecuentes en la FAQ.