¿Qué son las pruebas de regresión? Comprobar que la corrección no rompió otra cosa

Las pruebas de regresión comprueban que lo que funcionaba sigue funcionando después de un cambio. No el cambio en sí - eso se prueba mientras se escribe - sino todo lo que hay alrededor, que nadie tocó y que nadie esperaba que se viera afectado.

El nombre es la idea. Una regresión es un paso atrás: una función que funcionaba en la última versión y no funciona en esta. Estas pruebas existen porque el software está conectado de maneras que nadie tiene en la cabeza, y el código de descuento que alguien arregló el martes comparte una función con el cálculo de impuestos que nadie mira desde marzo.

Por qué es trabajo de alguien

Todo cambio tiene un radio de impacto mayor que su diff. Una función compartida, una columna de base de datos que se lee en seis sitios, una regla CSS que resultó ser estructural para una página que su autor nunca había abierto.

El fallo que esto evita es concreto y caro: una versión que corrige un error reportado e introduce dos que nadie ha reportado. Esos cuestan mucho más que el original, porque nadie los está buscando. Al error reportado le esperaba alguien; los nuevos los descubren los clientes, días después, sin idea de qué ha cambiado.

Qué volver a probar de verdad

No puedes volver a probarlo todo en cada cambio, y los equipos que lo intentan acaban con una suite tan lenta que se salta. Las pruebas de regresión son un problema de selección, y la selección va por riesgo.

Vale la pena volver a probar en casi cualquier cambio:

• Los caminos que dan dinero. Registro, inicio de sesión, compra, pago. Todo lo demás puede esperar al lunes; esto no.
• Lo que el cambio toca de verdad, más todo lo que comparte con él una función, una tabla o una plantilla.
• Cualquier cosa que se haya roto antes. Un defecto que volvió una vez volverá otra, y un error que ha regresado es el mejor argumento para una prueba permanente.
• Las integraciones que no controlas. Todo lo que llega a otro servicio falla por motivos que no tienen nada que ver con tu versión.

No vale la pena cada vez: pantallas de configuración que casi nadie usa, herramientas de administración con dos usuarios, cualquier cosa cuyo fallo alguien notaría y reportaría sin consecuencias.

Dónde termina el smoke test y empieza esto

Se hacen en momentos distintos y responden preguntas distintas.

Smoke test

¿Merece la pena probar esta compilación? Cinco comprobaciones, minutos, se ejecuta primero, en cada compilación

Prueba de regresión

¿Ha dejado de funcionar algo que antes funcionaba? Cientos de comprobaciones, más tiempo, se ejecuta cuando la compilación ya se ha ganado el sitio

Ejecutar una suite de regresión contra una compilación que no puede iniciar sesión gasta una hora en demostrarlo de cuatrocientas formas. El smoke test va primero exactamente por eso.

A mano o automatizado

La automatización es la respuesta obvia y la incompleta.

Automatiza lo que es estable, valioso y aburrido: los caminos del dinero, los contratos de la API, los cálculos con entradas conocidas y respuestas conocidas. Esos merecen escribirse una vez y ejecutarse siempre, y son las pruebas que cazan una regresión a las tres de la madrugada sin que nadie esté mirando.

Guarda a una persona para lo que un script no puede juzgar. Si la maquetación está mal y no solo distinta. Si un mensaje de error tiene sentido. Si el flujo sigue sintiéndose como algo que funciona. Una comparación de capturas te dirá que once píxeles se han movido; no te dirá que el botón ha quedado por debajo de la línea de flotación en el portátil más común de tu base de usuarios.

La mayoría de los equipos acaban con una suite automatizada para los caminos que no pueden romperse y una pasada manual corta para las zonas que tocó la versión.

Cómo se echa a perder una suite

De tres maneras, todas comunes, y cada una termina con la suite ignorada.

Se vuelve lenta. Una suite que tarda noventa minutos se ejecuta de noche en lugar de en cada cambio, y sobre una regresión encontrada a la mañana siguiente ya se ha construido encima.

Se vuelve inestable. Una prueba que falla una vez de cada diez enseña a todo el mundo a relanzarla, y la costumbre de relanzar es indistinguible de no tener la prueba. Una cosa realmente rota se esconde en el ruido de las que solo son poco fiables.

Solo crece. Se añaden pruebas por cada defecto y no se quita ninguna, hasta que media suite cubre comportamiento que el producto ya no tiene. Borrar pruebas es parte de mantenerlas.

Cuando aparece una regresión

Una prueba de regresión fallida es un informe de error pendiente de escribir, y arranca con más información de la que reciben la mayoría de los informes: sabes que antes funcionaba, y a menudo en qué versión exacta dejó de hacerlo.

Dilo. “Funcionaba en 4.2.0, falla en 4.3.0” convierte una investigación en un diff. Es la frase más útil de un informe de regresión y la que más se omite, porque quien lo escribe da por hecho que todo el mundo lo sabe.

Para una regresión con la que alguien tropieza a mano, en lugar de una que cazó la suite, el contexto es lo que suele perderse.

El resto de lo que necesita un buen informe está en la guía del informe de error, y su plantilla tiene una línea para la versión que sí funcionaba.

La versión corta

Las pruebas de regresión preguntan si el cambio que hiciste rompió algo que no hiciste. Elige qué volver a probar por riesgo y no por ambición, pon los caminos del dinero bajo automatización, guarda a una persona para los juicios que un script no puede hacer, y borra pruebas con la misma facilidad con la que las añades. Cuando encuentres una, di en qué versión funcionaba por última vez.