¿Qué son las pruebas de regresión? Pruebas end-to-end sin código
Qué son las pruebas de regresión, y por qué las pruebas de regresión end-to-end detectan lo que las pruebas unitarias no ven: qué cubrir, cuándo ejecutarlas y cómo automatizarlas sin código.
11 min de lecturaPor el equipo de GUI Test Studio
¿Qué son las pruebas de regresión?
Definición
Las pruebas de regresión comprueban que un cambio en una aplicación no rompió algo que ya funcionaba.
- Una función nueva, la corrección de un bug, la actualización de una biblioteca o una nueva versión del navegador pueden romper cada una una parte de la aplicación que nadie tocó.
- Las mismas pruebas se ejecutan de nuevo después del cambio, y una prueba que pasaba antes y ahora falla ha encontrado una regresión.
La palabra viene de ir hacia atrás: la aplicación retrocedió, hoy funciona peor que ayer.Eso es lo que hace que una regresión resulte tan frustrante para los usuarios.Algo en lo que confiaban simplemente dejó de funcionar.
Las regresiones ocurren porque las partes de una aplicación dependen unas de otras de formas que nadie tiene presentes.Un estilo compartido, una regla de redondeo, un campo renombrado en una API: un pequeño cambio en un sitio llega a pantallas muy alejadas de él.La persona que hizo el cambio comprobó lo que cambió, y tenía razón.La rotura está en otra parte.
Pruebas de regresión frente a repetición de pruebas
Las dos se confunden a menudo, y responden a preguntas distintas.
| Pregunta | Repetición de pruebas | Pruebas de regresión |
|---|---|---|
| ¿Qué comprueba? | Que un bug que usted corrigió está realmente corregido. | Que la corrección, o cualquier otro cambio, no rompió nada más. |
| ¿Dónde mira? | En el lugar del bug. | En todas las demás partes, sobre todo en aquello de lo que dependen los usuarios. |
| ¿Qué pruebas? | Los pasos que mostraron el bug. | La misma suite, ejecutada de nuevo después de cada cambio. |
| ¿Cuándo? | Una vez, después de la corrección. | Después de cada cambio, durante toda la vida de la aplicación. |
Pruebas de regresión unitarias, de integración y end-to-end
Hay pruebas de regresión en todos los niveles de una aplicación, y cada nivel ve una parte distinta de ella.
Cuánto de la aplicación ve cada prueba
Pruebas unitarias
Una función, sola
Detecta: Un cálculo que devuelve un valor incorrecto
Pruebas de integración
Dos o tres partes juntas
Detecta: Un servicio que ya no responde como espera el siguiente
Pruebas end-to-end
Toda la aplicación, a través de su pantalla
Detecta: Un total, un botón, una página o un mensaje que el usuario ve roto
Las pruebas unitarias y de integración son rápidas y precisas, y todo equipo debería tenerlas.Pero comprueban el código tal como lo concibe el desarrollador.Un usuario nunca llama a una función: hace clic en un botón, lee un total y espera que se abra la página siguiente.
Algunas regresiones solo existen en la pantalla, donde las pruebas unitarias nunca miran.
- Un cambio de estilo oculta el botón Pagar detrás de un banner.
- Un total se calcula bien y se muestra con la moneda equivocada.
- Un diálogo se abre detrás de la ventana.
- Una traducción es demasiado larga y la etiqueta queda cortada.
Por eso las pruebas de regresión end-to-end son las que más importan: una prueba end-to-end maneja toda la aplicación a través de su interfaz, como la recorre un usuario, y comprueba lo que ve el usuario.Consulte qué son las pruebas end-to-end para tener la visión completa.
Sus usuarios no ejecutan sus pruebas unitarias.Ejecutan su aplicación, pantalla tras pantalla.
Pruebas de regresión funcionales y no funcionales
Las pruebas funcionales comprueban lo que hace la aplicación: el pedido se realiza, el informe se exporta, el mensaje de error aparece cuando un campo está vacío.Las pruebas no funcionales comprueban cómo lo hace: con qué rapidez, qué aspecto tiene, cómo se comporta en otro dispositivo o en una red lenta.
Regresión funcional
El pago sigue realizando el pedido, y la confirmación sigue mostrando el número de pedido.
Regresión visual
La pantalla sigue viéndose como antes: ningún icono que falte, ninguna palabra cortada, ningún botón del color equivocado.
Regresión no funcional
La página sigue cargando a tiempo, y el diseño se mantiene en un teléfono y con una conexión lenta.
La mayoría de las suites de regresión son funcionales, y la mayoría de las roturas visuales y de diseño se les escapan porque una comprobación funcional pregunta si un elemento existe, no si una persona puede verlo.Errores visuales que sus pruebas automatizadas no detectan explica por qué.
¿Qué debe incluir una suite de regresión end-to-end?
Una suite de regresión que intenta cubrirlo todo nunca se termina y nunca inspira confianza.Empiece con poco, con lo que más dolería si se rompiera.
- 1
Enumerar los recorridos sin los que los usuarios no pueden vivir
Registro, inicio de sesión, búsqueda, pago, el informe que sus clientes exportan cada lunes.Entre cinco y diez recorridos, cada uno desde el primer clic hasta el resultado que espera el usuario.
- 2
Añadir lo que ya se rompió antes
Cada bug que llegó una vez a los usuarios merece una prueba, para que nunca pueda volver sin que nadie lo note.Así es como aprende una suite de regresión.
- 3
Ponderar por riesgo, no por número de pantallas
Una pantalla que usan todos los clientes cada día importa más que diez páginas de configuración.El dinero, los datos y el inicio de sesión van primero.
- 4
Comprobar resultados, no solo clics
Una prueba que recorre el pago a base de clics y nunca comprueba el total demuestra poco.Cada recorrido termina en lo que el usuario vino a buscar, y la prueba lo verifica: el total, la confirmación, el archivo exportado.
- 5
Mantenerla lo bastante rápida para ejecutarla en cada cambio
Marque unos pocos recorridos como la suite de humo, los que se ejecutan en cada pull request en pocos minutos.El resto se ejecuta cada noche.
¿Cuándo deben ejecutarse las pruebas de regresión?
Cuanto antes se encuentra una regresión, más barata resulta: el cambio sigue fresco en la mente del desarrollador, y todavía no se ha construido nada encima.
| Cuándo | Qué se ejecuta | Por qué |
|---|---|---|
| Cada pull request o build | La suite de humo: los recorridos críticos. | Una rotura se detecta antes de fusionarse, mientras el cambio es pequeño. |
| Cada noche | La suite completa. | Todo se comprueba una vez al día, sin frenar a nadie. |
| Antes de una versión | La suite completa, en todos los navegadores y dispositivos que usted admite. | Lo que los usuarios recibirán de verdad se comprueba allí donde lo recibirán. |
| Después de una actualización que usted no controla | La suite completa. | Una nueva versión del navegador, del sistema operativo o de una biblioteca puede romper la aplicación sin que cambie una sola línea de su código. |
Recorrido de pago, últimos ocho builds
- #38
- #39
- #40
- #41
- #42
- Empezó a fallar#43
- #44
- #45
#42 la última ejecución superada#43 el cambio que hay que revisar primero#45 corregido y comprobado de nuevo
Por qué se abandonan las suites de regresión automatizadas
La mayoría de los equipos coinciden en que las pruebas de regresión deberían automatizarse.Muchos lo han intentado, y muchas suites automatizadas acaban desactivadas o ignoradas.Los motivos son casi siempre los mismos.
Mantener la suite cuesta más de lo que ahorra.
- Las pruebas programadas encuentran los botones mediante selectores, y cada rediseño rompe docenas de ellos a la vez.
- Solo los desarrolladores pueden arreglarlas, y los desarrolladores están creando funciones.
- Las pruebas fallan por motivos inofensivos, un matiz de color o un píxel de suavizado, así que la gente deja de leer los resultados.
- La suite completa tarda horas, así que se ejecuta una vez por semana, y las regresiones esperan días a que alguien las encuentre.
Automatizar las pruebas de regresión end-to-end sin código
GUI Test Studio está pensado para las pruebas de regresión end-to-end de aplicaciones web, aplicaciones de escritorio de Windows, teléfonos y videojuegos, a través de su interfaz, sin código de prueba que escribir ni mantener.
Grabar cada recorrido una vez
Haga clic en Grabar en GUI Test Runner-Recorder y realice el recorrido en su aplicación real, como lo haría un usuario.Los clics, lo que escribe y las comprobaciones de lo que apareció se convierten en una prueba.También puede describir el recorrido en una petición a su asistente de IA, y la prueba se crea por usted.
La prueba comprueba lo que muestra la pantalla, no el código que hay detrás.
- Una aserción visual compara la imagen de un elemento, una aserción de texto lee sus palabras.
- El GTS Engine + AI encuentra cada elemento primero mediante la información de accesibilidad de la aplicación, y visualmente cuando la aplicación no lo dice, así que rediseñar el código que hay detrás de un botón no rompe la prueba.
Editarla como un vídeo
Cada prueba se abre en GUI Test Studio en una línea de tiempo: sus pasos como bloques, sus comprobaciones junto a ellos, la grabación encima.Cambie una comprobación, añada una espera, agrupe los pasos de un recorrido: sin código, y cualquier persona del equipo puede hacerlo.Consulte la línea de tiempo.
Ejecutarla en cada build
gtr-cli ejecuta la suite en una máquina de build Windows y responde como espera un pipeline: una prueba fallida hace fallar el build, un archivo JUnit rellena la pestaña de pruebas y se conserva cada imagen de lo que falló.
gtr-cli run tests\regression --countdown 0 --junit results\junit.xml --artifacts results\artifactsFunciona en TeamCity, Jenkins, GitHub Actions, GitLab y Azure DevOps.Consulte Ejecutar pruebas en su pipeline.
¿Una regresión real, o ruido inofensivo?
Cada ejecución termina en un Informe de confianza.Para cada comprobación, dice si se encontró el elemento y si sigue viéndose como se grabó, con las imágenes esperada y encontrada una al lado de la otra y la diferencia resaltada.
El ruido se ignora y las regresiones se detectan.
- No se cuentan las pequeñas diferencias de renderizado que ninguna persona notaría.
- Una palabra cambiada, una insignia que falta o un botón que se volvió gris hacen fallar la comprobación.
- Cuando una imagen difiere, el Análisis inteligente con IA puede echar un segundo vistazo y decir qué cambió en palabras sencillas.
Un cambio intencionado se acepta con un clic
No toda diferencia es una regresión: a veces la pantalla nueva es la correcta.En el Informe de confianza, acepte lo que encontró la ejecución como la nueva imagen esperada, y la siguiente ejecución compara con ella.Para las pantallas que difieren a propósito, un modo oscuro u otro idioma, las líneas base conservan una versión por entorno.
Saber cuándo empezó
Cada ejecución se conserva en el Historial de la prueba.Cuando un recorrido empieza a fallar, el Historial muestra la última ejecución superada y la primera fallida, y se pueden comparar dos ejecuciones comprobación por comprobación.
Todos los navegadores y dispositivos, y un bug en su gestor de incidencias
Una prueba web grabada una vez se ejecuta en Chrome, Edge y Firefox, en teléfonos y tabletas, en otros idiomas y tamaños de pantalla: consulte las pruebas entre navegadores.Y una ejecución fallida puede convertirse por sí sola en una incidencia de Jira, con los pasos para reproducir y las imágenes: consulte las pruebas fallidas como bugs de Jira.
Se envía un cambio
Una función, una corrección, una actualización
Se ejecuta el build
gtr-cli ejecuta la suite
Informe de confianza
Regresión o ruido, con imágenes
Fusionar, o corregir primero
Un fallo bloquea el cambio
Hacer
- Una suite pequeña de recorridos críticos en cada build
- Comprobaciones de lo que ve el usuario al final de cada recorrido
- Una prueba para cada bug que llegó a los usuarios
- Todos los navegadores y dispositivos antes de una versión
Evitar
- Una suite tan grande que solo se ejecuta una vez por semana
- Pruebas que recorren un camino a base de clics y no verifican nada
- Fallos que nadie lee porque la mitad son ruido
- Pruebas que solo los desarrolladores pueden cambiar
Lo esencial
- 1Las pruebas de regresión comprueban que un cambio no rompió nada que funcionaba. Las mismas pruebas, ejecutadas de nuevo después de cada cambio.
- 2La repetición de pruebas demuestra una corrección; las pruebas de regresión demuestran que la corrección no costó nada más.
- 3Las pruebas de regresión end-to-end detectan lo que notan los usuarios: los totales, botones, páginas y mensajes que las pruebas unitarias nunca ven.
- 4Empiece con poco: entre cinco y diez recorridos críticos en cada build, la suite completa cada noche, todos los navegadores y dispositivos antes de una versión.
- 5Una suite debe distinguir una regresión del ruido, y costar poco de mantener, o acabará abandonada.
Preguntas
¿Qué son las pruebas de regresión?
Las pruebas de regresión comprueban que un cambio en una aplicación no rompió algo que ya funcionaba.Después de una función nueva, la corrección de un bug o una actualización, las mismas pruebas se ejecutan de nuevo, y cualquier prueba que pasaba antes y ahora falla señala una regresión.
¿Qué diferencia hay entre las pruebas de regresión y la repetición de pruebas?
La repetición de pruebas comprueba que un bug que usted corrigió está realmente corregido.Las pruebas de regresión comprueban que la corrección, o cualquier otro cambio, no rompió el resto de la aplicación.La repetición de pruebas mira en un solo lugar, las pruebas de regresión miran en todos los demás.
¿Qué son las pruebas de regresión end-to-end?
Las pruebas de regresión end-to-end ejecutan los recorridos importantes de una aplicación a través de su interfaz, como los realiza un usuario, después de cada cambio.Detectan las roturas que solo se ven en la pantalla: un total incorrecto, un botón que ya no abre su diálogo, una página que no carga.
¿Las pruebas de regresión son funcionales o no funcionales?
Ambas cosas.La mayoría de las pruebas de regresión son funcionales: comprueban que las funciones siguen haciendo lo que deben.Una regresión también puede ser no funcional, como una página que se volvió lenta o un diseño que se rompió en un teléfono, y esas merecen sus propias pruebas.
¿Con qué frecuencia hay que ejecutar las pruebas de regresión?
Ejecute una suite corta de recorridos críticos en cada pull request o build, la suite completa cada noche, y la suite completa en todos los navegadores y dispositivos antes de una versión.Cuanto antes se detecta una regresión, más barato es corregirla.
¿Se pueden automatizar las pruebas de regresión sin escribir código?
Sí.Con GUI Test Studio, usted graba un recorrido una vez usando la aplicación, o lo describe en una petición, y la prueba se crea por usted.Se vuelve a ejecutar en cada build con gtr-cli, y nadie tiene que mantener código de prueba.
¿Qué son las pruebas de regresión visual?
Las pruebas de regresión visual comparan lo que muestra ahora la pantalla con lo que mostraba antes, para detectar cambios que vería un usuario: un icono que falta, una palabra cortada, un botón del color equivocado.Son un tipo de comprobación de regresión end-to-end.
OpenAI, Anthropic, Jira, TeamCity, Jenkins, GitHub, GitLab, Azure DevOps, Chrome, Edge y Firefox son marcas comerciales de sus respectivos propietarios.
¿Listo para grabar su primera prueba?
Todas las funciones, durante 15 días.
¿Prefiere verlo con el tipo de aplicación que prueba?Reserve una llamada gratuita de 30 minutos con nuestro equipo.