Glosario de pruebas de regresión y test visual: 40 términos esenciales

Glosario de pruebas de regresión y test visual: 40 términos esenciales

Su sitio web es su mejor comercial. Imagine que un cliente llega a su tienda y el botón "Comprar" está oculto tras una imagen por culpa de una actualización mal gestionada. El cliente pierde confianza y se va. Esto es lo que se llama un bug visual.

Para evitar estas pérdidas de ingresos, los profesionales utilizan el test visual. Si desea profundizar en el método más utilizado para detectar regresiones, consulte nuestra guía del test de regresión visual. Esta guía le explica los conceptos clave para supervisar su sitio y preservar su imagen de marca.

Lo esencial en una página (definición, automatización sin código, guía para elegir una herramienta): Pruebas de regresión automatizadas, sin código.

Un botón «Comprar» oculto por una actualización, y el cliente se va. Vea en concreto qué es una diff visual o una baseline probando Delta-QA, gratis y sin tarjeta de crédito. Probar Delta-QA gratis →


Parte 0: el vocabulario de las pruebas de regresión y de aceptación

Antes de hablar de capturas y comparaciones, hace falta fijar las palabras que los equipos de proyecto, las consultoras y los departamentos de TI usan a diario para organizar sus pruebas.

  • Pruebas de regresión Verificación de que las funcionalidades existentes de una aplicación siguen comportándose como se espera después de un cambio: una corrección, una nueva funcionalidad, una actualización de dependencia. No se prueba la novedad, se protege lo ya adquirido. Aviso: «regresión» por sí sola también remite a la regresión estadística; use «pruebas de regresión» para evitar ambigüedad. Guía completa: Pruebas de regresión automatizadas, sin código.

  • Pruebas de confirmación (re-test) Verificación de que un bug corregido lo está realmente. Se centra en el defecto concreto; las pruebas de regresión, en cambio, verifican que la corrección no ha roto nada más.

  • Regresión Defecto que reaparece o se introduce en una parte de la aplicación que funcionaba antes del cambio. Una regresión puede ser funcional (un cálculo erróneo), visual (un botón desaparecido) o de rendimiento.

  • Campaña de regresión Ejecución, en cada entrega candidata, del conjunto de escenarios de referencia del alcance de regresión. Automatizada, tarda unos minutos; manual, tarda días y termina reduciéndose o saltándose.

  • Alcance de regresión Lista de los recorridos y funcionalidades cubiertos por la campaña de regresión. Debe evolucionar con la aplicación: es la primera razón por la que las pruebas de regresión deben poder ser mantenidas por el propio equipo de QA, sin depender de un desarrollador.

  • Pruebas de aceptación (UAT) Fase de validación antes de la puesta en producción, durante la cual el cliente o el negocio verifica que la entrega corresponde a la necesidad expresada. La aceptación se centra en la novedad; la regresión, en lo existente.

  • Plan de pruebas de aceptación Documento que enumera los casos a verificar antes de la puesta en producción, con el resultado esperado de cada uno. Los casos «a repetir en cada entrega» son el núcleo de una automatización de las pruebas de regresión. Guía relacionada: Guía de pruebas de aceptación de software.

  • Caso de prueba Descripción de una verificación única: un punto de partida, una secuencia de acciones, un resultado esperado. En una herramienta sin código, el caso de prueba es un recorrido grabado navegando.

  • Escenario de prueba Encadenamiento de casos de prueba que reproduce un uso real (iniciar sesión, buscar un producto, pagar). Es la unidad que se graba, se reproduce y se compara.

  • Prueba funcional Verificación de que la aplicación hace lo que debe hacer: un formulario se envía, un cálculo es correcto, un estado cambia. Complementa a las pruebas visuales, que verifican lo que ve el usuario.

  • Smoke test Verificación rápida de que una entrega arranca y de que los recorridos vitales responden, antes de lanzar la campaña de regresión completa.

  • Automatización de pruebas Confiar la ejecución y verificación de las pruebas a un software, en lugar de a una persona que hace clic. Históricamente reservada a desarrolladores (scripts de Selenium, Cypress, Playwright), hoy es accesible sin código. Ver Automatización de pruebas sin código.

  • Pruebas sin código (no-code) Creación y mantenimiento de pruebas automatizadas sin escribir un script: la herramienta graba un recorrido realizado en el navegador, lo reproduce y compara el resultado. El no-code elimina el coste técnico, no el criterio de QA.

  • Grabación y reproducción (record and replay) Mecanismo de las pruebas sin código: una navegación real se captura una vez y luego se reproduce automáticamente en cada entrega, en uno o varios navegadores.

  • Selector Dirección técnica de un elemento de la página (un identificador, una clase CSS, una ruta) que un script de prueba usa para hacer clic o leer un valor. Un selector que cambia rompe el script sin que la aplicación tenga culpa: es la primera fuente de mantenimiento de las pruebas con código.

  • Entorno de pruebas (staging) Copia de la aplicación, aislada de producción, sobre la que se reproduce la campaña de regresión antes de la puesta en línea.


Parte 1: Las bases de la supervisión visual

Para garantizar una experiencia de usuario impecable, es esencial comprender cómo un sistema de test visual supervisa su interfaz.

  • Imagen de referencia Es la versión validada de su sitio web. La herramienta la utiliza como estándar de calidad. Cualquier modificación futura se comparará automáticamente con esta referencia para detectar la menor desviación.

  • Captura de pantalla Es la foto instantánea que el robot toma de su sitio hoy. Se compara con el modelo de referencia para detectar los menores desvíos de diseño.

  • Test visual automatizado Consiste en confiar la supervisión de su sitio a un software. Verifica automáticamente cada página después de cada modificación, sin intervención humana.

  • Error de visualización Es un problema visual que degrada la experiencia del usuario, como un texto que se desborda o un logotipo mal alineado. El sitio funciona técnicamente, pero proyecta una imagen poco profesional.


Parte 2: Cómo funciona un escenario de test

Un test no es una simple foto aislada, es un recorrido lógico por su sitio web.

  • Grabación de recorrido Usted navega normalmente por su sitio (inicio de sesión, añadir al carrito, lectura de un artículo) y la herramienta registra sus movimientos para poder reproducirlos sola más tarde.

  • Escenario de test Es la secuencia lógica de acciones que ha grabado. Es el camino a reproducir cada día para asegurarse de que el recorrido de sus clientes sigue siendo impecable.

  • Punto de control Es una etapa precisa del escenario donde se toma una foto. Usted define estos puntos en las páginas más importantes para su negocio.

  • Reproducción automática Es el momento en que el robot ejecuta el escenario en su lugar. Verifica sin intervención humana y automáticamente en pocos minutos, lo que normalmente le llevaría medio día de verificación manual.


Parte 3: Analizar y corregir los errores

Detectar un problema es una cosa, comprender cómo resolverlo es otra.

  • Imagen de diferencia Cuando se detecta un cambio, se genera una imagen que resalta las zonas modificadas. Usted comunica a los desarrolladores exactamente qué ha cambiado.

  • Diferencia de píxeles Al comparar dos capturas de pantalla, algunas herramientas o un script desarrollado a medida calculan el número exacto de píxeles que difieren entre las dos imágenes. Esta puntuación numérica permite medir la magnitud bruta del cambio: unos pocos píxeles modificados señalan a menudo un detalle técnico (un anti-aliasing, un redondeo de fuente), mientras que miles de píxeles diferentes indican una anomalía más seria. Su límite es conocido: no distingue el ruido de renderizado de una verdadera regresión. Delta-QA responde a este límite con un motor determinista calibrado sobre la percepción humana, que solo señala lo que un ojo notaría.

  • Umbral de tolerancia Es el ajuste que permite evitar falsas alertas. Por ejemplo, si el borde de un bloque cambia muy ligeramente de color o posición, no es necesariamente un error grave. El umbral permite decirle al robot que ignore estas diferencias para señalar solo los cambios que realmente importan al usuario.

  • Alerta de cambio Algunas herramientas de test visual, como Delta-QA, envían automáticamente una notificación en cuanto se detecta una desviación importante. Ya sea por email, vía Slack o directamente en su pipeline CI/CD, estas alertas le permiten actuar inmediatamente, antes incluso de que sus clientes se den cuenta.


Ya dominas el vocabulario, ahora protege tu sitio de los bugs visuales. Pon en práctica estos términos con Delta-QA, gratis y sin tener que registrarte. Probar Delta-QA gratis →

Parte 4: Evitar las trampas y las falsas alertas

Una herramienta de test visual eficaz debe ser precisa sin generar alertas innecesarias. Estos son los mecanismos que le permiten concentrar su atención en los problemas reales.

  • Falsa alerta Ocurre cuando el robot señala un cambio en un elemento que cambia constantemente, como una fecha, un precio dinámico o un anuncio publicitario.

  • Zona de exclusión Es la solución a las falsas alertas. Usted dibuja un marco alrededor de las zonas cambiantes para decirle al robot que ignore esa parte y se concentre en el resto de la página.

  • Error no detectado Es el caso más problemático: un verdadero bug visual que la herramienta no detectó porque el umbral de tolerancia estaba demasiado alto. Por eso es indispensable una calibración precisa desde la configuración inicial.

  • Estabilidad del test Se dice que un test es estable cuando solo genera alertas por problemas reales de diseño, sin verse perturbado por detalles técnicos sin importancia.


Parte 5: La evolución hacia herramientas accesibles

El test visual moderno ya no está reservado a los ingenieros informáticos. Ahora se abre a todos los perfiles (diseño, marketing, producto).

  • Enfoque No-Code Es una tendencia importante del sector. El objetivo es permitir a cualquier usuario crear tests sin escribir líneas de código complejas, utilizando interfaces simplificadas.

  • Ciclo de mantenimiento En un proyecto web, el diseño cambia a menudo. Una buena solución de test permite actualizar las referencias fácilmente. Cuando una modificación es validada, el nuevo diseño pasa a ser la referencia en un clic.

  • Soberanía de datos Algunas herramientas permiten conservar los datos de test (imágenes, capturas) en la infraestructura de la empresa o en local, garantizando que los datos sensibles no se almacenen en un cloud externo no controlado.

  • Interfaz de Usuario (UI) intuitiva Para que el test sea adoptado por todo un equipo, la herramienta debe ser tan simple como un navegador web. Una interfaz clara permite a los no informáticos pilotar la calidad sin formación técnica pesada.


Parte 6: Adaptarse a la realidad de los usuarios

Sus clientes utilizan dispositivos variados. Su supervisión debe tenerlo en cuenta.

  • Ventana de visualización Es el tamaño de pantalla simulado por el robot. Es crucial probar su sitio en una ventana estrecha para móvil y una ventana amplia para ordenador, porque los bugs nunca son los mismos.

  • Test adaptativo Esto verifica que su sitio se reorganiza correctamente según la pantalla. Un buen test se asegura de que el menú no oculte el logotipo en smartphone, por ejemplo.

  • Multi-navegadores Su sitio no se muestra de la misma manera en Chrome, Safari o Firefox. El robot verifica la coherencia visual en todos estos navegadores para no perder ningún cliente.

  • Pantallas de Alta Definición Algunas pantallas modernas muestran muchos más detalles. Una herramienta profesional sabe diferenciar entre una mejora de nitidez y un verdadero bug de diseño.


¿Por qué supervisar su sitio es una prioridad de negocio?

Un sitio web que presenta defectos visuales cuesta caro. Degrada su imagen de marca, siembra la duda en sus prospectos y puede frenar en seco un proceso de compra.

El test visual automatizado es su red de seguridad. Supervisa lo que el ojo humano no puede verificar a gran escala. Con una solución adaptada, usted retoma el control total sobre la calidad de su escaparate digital en pocos clics, sin necesitar un equipo técnico dedicado.

Invirtiendo unos minutos en implementar estos tests, se ofrece tranquilidad: su sitio seguirá siendo profesional, día tras día.

¿Listo para poner este vocabulario al servicio de su sitio? Lance su primera comparación con Delta-QA, gratis y sin tarjeta de crédito, y retome el control sobre su escaparate digital. Probar Delta-QA gratis →


FAQ

¿Qué son las pruebas de regresión?

Es la verificación de que lo que funcionaba antes de un cambio sigue funcionando después. Se reproducen escenarios de referencia y se compara el resultado obtenido con el resultado esperado, tanto en los valores como en la representación visual.

¿Cuál es la diferencia entre pruebas de aceptación y pruebas de regresión?

Las pruebas de aceptación (UAT) validan la novedad entregada frente a la necesidad expresada; las pruebas de regresión protegen lo existente. Las pruebas de aceptación siguen siendo en gran parte manuales, mientras que las pruebas de regresión son la candidata ideal para la automatización, sin código.