Respuesta.

La prueba regresiva manual es el proceso de verificar nuevamente las funciones del sistema que ya se han probado después de haber realizado cambios en el código, para asegurarse de que estos cambios no hayan causado nuevos defectos en las partes estables del producto.

Historia de la cuestión: Al principio del ciclo de vida del software, los probadores suelen centrarse en verificar las nuevas funciones. Con el tiempo, el sistema acumula cambios, lo que aumenta el riesgo de aparición de regresiones no deseadas. Muchos errores en la historia del software surgieron precisamente después de un arreglo que "rompió" algo que antes funcionaba, por lo que las pruebas regresivas gradualmente se convirtieron en una práctica obligatoria.

Problema: La principal dilema es cómo, ante cambios constantes, revisar de manera efectiva y rápida la máxima cantidad de funciones. Si se aborda la tarea de manera caótica o inconsistente, se pueden pasar por alto defectos críticos, no cumplir con los plazos, sobrecargar al equipo, y a veces las pruebas se vuelven una formalidad.

Solución: Para organizar de manera efectiva las pruebas regresivas, es necesario:

Tener un conjunto de casos de prueba o listas de verificación estables y mantenidas para las funciones clave;
Actualizar regularmente estos conjuntos al hacer modificaciones;
Automatizar la rutina siempre que sea posible, y seleccionar escenarios críticos o no estándar para las pruebas manuales;
Alinear las prioridades de las funciones a verificar en función de los riesgos comerciales y la frecuencia de cambios.

Características clave:

La regresión no solo identifica errores evidentes, sino también cadenas de errores ocultos relacionadas con la interacción de módulos.
Es importante revisar y priorizar regularmente los conjuntos de casos de prueba.
La estrategia óptima es combinar las revisiones manuales con las automatizadas donde sea posible.

Preguntas capciosas.

¿En qué etapa es mejor comenzar la prueba regresiva: después de todos los cambios o paralelamente a su implementación?

Muchos piensan erróneamente que la regresión se realiza solo después de finalizar todos los cambios. En realidad, es más correcto planificarla y realizarla de manera parcial conforme se realizan los cambios, para poder reaccionar más rápido a las fallas críticas.

¿Es suficiente escribir una vez un caso de prueba regresivo y no volver a actualizarlo?

No, los casos de prueba para la regresión requieren actualización constante: con el cambio de la lógica del negocio o de la interfaz, el sistema de pruebas debe cambiar junto con el producto.

¿Es la prueba smoke parte de la regresión?

No, la prueba smoke es un filtrado rápido de fallos evidentes después de la compilación, mientras que la regresión cubre una funcionalidad más amplia y busca fallos "en profundidad".

Errores típicos y anti-patrones

Casos de prueba desactualizados: debido a esto, las pruebas se convierten en una formalidad inútil.
Ignorar escenarios poco evidentes, pero importantes.
Falta de priorización clara: poner la misma atención a funciones clave y a las poco importantes.

Ejemplo de la vida real

Caso negativo

El equipo realiza un lanzamiento, el probador comprueba formalmente las características con una lista de casos de prueba obsoleta, sin saber sobre la última modificación de la API. Un error antiguo se corrige, pero aparece un defecto crítico en otra parte del sistema que nadie notó hasta el lanzamiento.

Ventajas:

Ahorro de tiempo en desarrollar casos de prueba.

Desventajas:

Alto riesgo de pasar por alto regresiones importantes.
Se reduce la confianza en la calidad de las pruebas.

Caso positivo

Antes del lanzamiento, los probadores actualizaron las listas de verificación regresivas, discutieron con los analistas las áreas de riesgo actuales, priorizaron las pruebas basándose en escenarios reales y llevaron a cabo la regresión manual en flujos clave.