Resulta que cada vez que se añade un nuevo módulo a la aplicación, o cuando se modifica, el software cambia.

Como resultado de esa modificación (o adición) de módulos, podemos introducir errores en el programa que antes no teníamos. Por ello, se hace necesario volver a probar la aplicación. La prueba de regresión es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados.

Así, el objetivo de las pruebas de regresión es comprobar que los cambios sobre un componente de una aplicación no introducen errores adicionales en otros componentes no modificados.

La prueba de regresión se puede hacer manualmente, volviendo a realizar un subconjunto de todos los casos de prueba o utilizando herramientas automáticas (es lo más frecuente).

El conjunto de pruebas de regresión contiene, a su vez, tres clases de prueba diferentes:

• Planificar una muestra de pruebas sobre todas las funciones del software.
• Plantear pruebas adicionales que se centren en las funciones del software que se van a ver afectadas por el cambio.
• Planificar pruebas que se centren únicamente en los componentes que han cambiado.

Es totalmente desaconsejable, por razones obvias de pérdida de tiempo, volver a realizar todas y cada una de las pruebas sobre cada uno de los componentes.

Actualmente, las pruebas de regresión son una parte integral del método de desarrollo de software conocido como Programación Extrema (Extreme Programming). Se utilizan herramientas que permiten detectar este tipo de errores de manera parcial o totalmente automatizada en cada una de las fases del desarrollo del software.