Errores visuales que sus pruebas no detectan: probar lo que ve el usuario

¿Qué son los errores visuales?

Sus pruebas de extremo a extremo están en verde.Entonces un cliente envía una captura de pantalla de la página de pago: el total del pedido queda oculto tras un banner promocional.Todas las pruebas automatizadas se superaron, porque todas preguntaron al código de la página, no a la pantalla.Para errores visuales como este existen las pruebas visuales: comprueban lo que sus usuarios ven realmente.

Un error visual es un defecto que las personas ven en la pantalla mientras el código que hay detrás parece correcto.El elemento existe, tiene un tamaño, contiene el texto correcto.Una comprobación del código se supera.La persona que está frente a la pantalla no puede leerlo, encontrarlo ni pulsarlo.

Este artículo muestra de dónde viene esa brecha, qué errores caen en ella y cómo crear pruebas de extremo a extremo que vean la pantalla como la ven sus usuarios.

Qué significa «visible» para Playwright, Cypress y Selenium

Una prueba de extremo a extremo en código encuentra un elemento mediante un selector y comprueba algo sobre él.La aserción más cercana a lo que vive un usuario es «¿es visible?».Cada herramienta la responde a su manera, y ninguna mira la pantalla.

Playwright

La aserción toBeVisible() de Playwright se supera cuando el elemento tiene un cuadro delimitador no vacío y ningún estilo visibility: hidden.Su documentación añade que un elemento con opacity: 0 cuenta como visible.No pregunta si otro elemento cubre al elemento, ni de qué color es su texto.

Las acciones son más estrictas que las aserciones.Antes de un clic, Playwright comprueba que el elemento es el que recibe el clic en ese punto, así que un botón cubierto hace que el clic espere hasta agotar su tiempo de espera.Playwright ofrece también toBeInViewport() para un elemento que debe estar dentro del área visible de la página, y toHaveText() lee por defecto el textContent del elemento.

Cypress

Desde Cypress 16, la comprobación de visibilidad predeterminada delega en el propio Element.checkVisibility() del navegador.Un elemento cuenta como oculto cuando su anchura o su altura es nula, o tiene display: none, visibility: hidden o, en una aserción, opacity: 0.Antes de un clic, Cypress comprueba que el centro del elemento no está cubierto.

Una aserción es otra cosa.La documentación de Cypress lo dice claramente: «El algoritmo moderno no comprueba qué elemento queda encima, así que informa de que el elemento cubierto es visible».

Selenium

El método isDisplayed() de Selenium no está definido en la especificación W3C WebDriver, debido a «la imposibilidad de cubrir todas las condiciones posibles», como lo expresa la documentación de Selenium.En su lugar, Selenium ejecuta una gran función de JavaScript que sopesa el estilo del elemento, su tamaño y los ancestros que lo recortan.No comprueba si otro elemento se dibuja encima de él, ni si su texto se puede leer sobre su fondo.

Un clic en un elemento cubierto falla con un error «element click intercepted».Un elemento que la prueba solo lee se sigue considerando mostrado.

9 errores visuales que superan una comprobación en código

Cada uno de estos errores deja el elemento en el código de la página, con un tamaño y el texto correcto.Una prueba en código que comprueba que el elemento existe, es visible o contiene su texto se supera.Su usuario ve otra cosa.

1. Un elemento cubierto por otro

Un aviso de cookies, un widget de chat, un encabezado fijo o un diálogo que nunca se cerró queda encima del elemento, a menudo tras un cambio de z-index.El elemento sigue siendo visible según todas las definiciones anteriores.Un clic en él se rechaza, pero una prueba que solo lo lee, como un precio, un mensaje de error o una confirmación, se supera mientras nadie puede verlo.

2. Texto que nadie puede leer

Texto blanco sobre fondo blanco, gris sobre gris tras un cambio de tema, o una etiqueta que una animación rota dejó transparente.Ninguna comprobación de visibilidad lee un color.La aserción toBeVisible() de Playwright también se supera con opacity: 0.

3. Texto cortado

Una etiqueta demasiado larga para su recuadro termina en puntos suspensivos, o una altura fija oculta la segunda línea.La página sigue conteniendo todas las palabras, así que una aserción que lee el texto se supera.Su usuario lee «Confirme su pe...».

4. Un elemento desplazado fuera de la vista

Una tabla más ancha o un encabezado más largo empuja el botón Comprar más allá del borde derecho de una pantalla estrecha.El botón conserva su tamaño, así que toBeVisible() se sigue superando.La prueba lo detecta solo si además pide toBeInViewport() para ese botón.

5. La imagen o el icono equivocados

Un producto muestra la foto de otro producto, una fuente de iconos falla y deja un cuadrado vacío, o una actualización del sprite intercambia dos iconos.El elemento de imagen y la clase del icono no cambian, así que el código parece correcto.

6. Un diseño roto por un cambio de CSS

Una regla cambia un margen, una dirección flex o una columna de la cuadrícula.Las tarjetas se solapan, una columna cae debajo de otra, un formulario pierde su alineación.Todos los elementos siguen en el código, con su texto y su tamaño, así que todas las aserciones se superan.

7. Una etiqueta traducida que no cabe

Las palabras en alemán o en francés suelen ser más largas que en inglés.Una etiqueta desborda su botón, salta a una segunda línea o empuja el botón siguiente.La traducción es correcta, así que una aserción sobre el texto se supera en todos los idiomas.

8. Una fuente que no se cargó

Cuando una fuente web no se carga, el navegador recurre a otra fuente: las líneas se cortan de otro modo, y los iconos dibujados con una fuente se convierten en cuadros vacíos.El texto del código es el mismo, así que nada falla.

9. Un indicador de carga que nunca se detiene

Los datos llegan y las filas se añaden a la página, pero la capa de carga se queda encima.La prueba encuentra sus filas en el código y se supera.Su usuario espera delante de un indicador de carga.

La propia documentación de Cypress lo resume en una línea: «una aplicación puede superar todas las pruebas funcionales y aun así publicarse visiblemente rota».

¿Pueden detectarlos las pruebas de regresión visual con capturas de pantalla?

Sí, y es la respuesta habitual.Las pruebas de regresión visual comparan una imagen de la pantalla con una imagen de referencia tomada antes.

Playwright lo trae integrado con toHaveScreenshot().Su documentación advierte que el renderizado del navegador puede variar según el sistema operativo del equipo, su versión y su configuración, el hardware y el modo headless.Por eso cada navegador y cada plataforma conserva su propia imagen de referencia.

Cypress hace capturas de pantalla, y su documentación dice que «no realiza por sí mismo la comparación de imágenes».Los plugins o los servicios de pruebas visuales añaden la comparación.

Servicios como Percy y Applitools Eyes añaden puntos de control con imágenes a sus pruebas en código.Percy toma y compara capturas de pantalla durante sus ejecuciones de prueba.Applitools Eyes añade una llamada de comprobación dentro de una prueba.

En ambos casos, su prueba en código tiene que llegar a cada pantalla y decir cuándo tomar la imagen: usted escribe y mantiene ese código, sus selectores y las imágenes de referencia.Una comparación de píxeles en bruto también señala diferencias inofensivas entre máquinas, así que su tolerancia se convierte en un compromiso entre falsas alarmas y errores no detectados.

Para ver estas herramientas lado a lado, consulte el estudio comparativo.

Por qué las pruebas manuales no cierran la brecha

Una persona ve cada uno de estos errores de un vistazo.Por eso muchos equipos siguen recorriendo su aplicación clic a clic antes de cada versión.Sin embargo, las pruebas manuales tienen sus límites.

Las pruebas automatizadas de extremo a extremo repiten las mismas comprobaciones en cada compilación sin cansarse.La cuestión es cómo hacer que miren la pantalla como lo hace una persona.

¿Cómo se crean pruebas de extremo a extremo que vean lo que ven los usuarios?

Sea cual sea la herramienta que use, seis principios hacen que una prueba de extremo a extremo viva su aplicación como un usuario.

1. 1

   Manejar la aplicación real

   Hacer clic y escribir como lo hace una persona, en la pantalla real.Una prueba que no puede pulsar un botón cubierto falla donde fallaría su usuario.

2. 2

   Comprobar lo que se muestra

   Comprobar la pantalla de tres maneras: la imagen, para que un elemento tenga el aspecto correcto; las palabras, para que diga lo correcto; la disposición, para que todo esté en su sitio.

3. 3

   Encontrar primero el elemento y después compararlo

   Una ventana que se movió o una página que se desplazó no es un error.Una prueba debe encontrar el elemento donde está ahora, y después juzgar su aspecto.

4. 4

   Ignorar el ruido, nunca un cambio real

   Las pantallas difieren ligeramente de una máquina a otra, así que la comparación debe ignorar el ruido de renderizado y aun así detectar cada cambio que notaría una persona.

5. 5

   Mostrar las evidencias

   Un fallo debe mostrar la pantalla esperada junto a la encontrada, con el cambio señalado, para que cualquiera del equipo pueda leerlo.

6. 6

   Mantener bajo el coste de los cambios

   Cuando la aplicación cambia a propósito, aceptar el nuevo aspecto debe costar un clic, no una reescritura.

Cómo prueba GUI Test Studio lo que ven los usuarios

GUI Test Studio crea pruebas de extremo a extremo con estos principios, sin código.Prueba aplicaciones web, aplicaciones de escritorio de Windows, teléfonos Android y videojuegos con un solo tipo de prueba.Lea más sobre las pruebas visuales y las pruebas de GUI con GUI Test Studio.

Grabar el flujo de trabajo una vez

En GUI Test Runner-Recorder, haga clic en Grabar y realice el flujo de trabajo como siempre: graba su ratón, su teclado y la pantalla.También puede describir el flujo de trabajo en una petición a Claude, a ChatGPT o a un modelo de IA local, uno nuestro o uno suyo, que lo graba por usted.

Cuando usted la detiene, le pregunta qué debe verificar la prueba.Con las respuestas predeterminadas, cada elemento en el que hace clic o escribe recibe una aserción visual justo antes de su acción.Lo que aparece por sí solo, como un menú, un diálogo o un mensaje, recibe una aserción de grupo.

Comprobaciones de lo que muestra la pantalla

Cada una tiene su guía: comprobaciones visuales, comprobaciones de texto y comprobaciones de disposición y de grupo.

Encontrar el elemento y después compararlo

Cada comprobación visual se decide en dos fases.La Fase de búsqueda pregunta si el elemento está en la pantalla, y lo espera hasta el tiempo de espera de la comprobación.El GTS Engine + AI encuentra el elemento preguntando primero a la aplicación, mediante su información de accesibilidad o los propios elementos de la página, y visualmente cuando la aplicación no lo dice.Consulte cómo encuentra GUI Test Studio cada elemento.

Después, la Fase de verificación compara de cerca el elemento con su objetivo visual, la imagen que espera la prueba.Ignora lo que el ojo no puede ver, como el suavizado y la compresión del vídeo, y aun así detecta las regresiones reales que una persona llamaría un cambio: una palabra distinta, un color, un icono.

Cuando el elemento se encuentra en un lugar distinto al de la grabación, los clics posteriores se dirigen a donde está ahora.Y una prueba nunca hace clic a ciegas a través de un banner: cuando el elemento está cubierto, su comprobación falla antes del clic.

Leer qué cambió

Tras una ejecución, el Informe de confianza muestra cada comprobación con la imagen esperada junto a la imagen encontrada, el cambio resaltado y el veredicto en una frase sencilla.

Ampliar

Con el Análisis inteligente con IA activado, una comprobación fallida recibe además una segunda mirada de una IA, que dice con palabras sencillas qué cambió.Funciona con un modelo en la nube y su propia clave, o con un modelo de IA local en su propio equipo: uno nuestro, o uno suyo.

Cuando el cambio es intencionado, acepte el nuevo aspecto desde el informe, y la prueba lo esperará a partir de entonces.La línea de comandos, gtr-cli, ejecuta las mismas pruebas desde cualquier pipeline de CI/CD, en cada compilación.

Qué comprobación detecta cada error visual

Los nueve errores de nuevo, con la comprobación de GUI Test Studio que detecta cada uno.

Ampliar

Dónde siguen teniendo su lugar las comprobaciones en código

Las pruebas visuales no sustituyen a sus pruebas unitarias y de API, que comprueban la lógica y los datos con rapidez, por debajo de la pantalla.Una comprobación en código que ya hace la pregunta correcta, como comprobar qué elemento recibe el clic antes de hacerlo, también conserva su lugar.Las pruebas visuales añaden la capa que ninguna de ellas puede ver: la pantalla que miran sus usuarios.

Preguntas

Selenium, Playwright, Cypress, Percy y Applitools Eyes son marcas comerciales de sus respectivos propietarios.