Pruebas de regresión

Las pruebas de regresión (en raras ocasiones, pruebas sin regresión ^{[ 1 ]} ) consisten en volver a ejecutar pruebas funcionales y no funcionales para asegurar que el software previamente desarrollado y probado siga funcionando como se espera después de un cambio. ^{[ 2 ]} De lo contrario, se denominaría una regresión .

Los cambios que pueden requerir pruebas de regresión incluyen correcciones de errores , mejoras de software, cambios de configuración e incluso la sustitución de componentes electrónicos ( hardware ). ^{[ 3 ]} Dado que los conjuntos de pruebas de regresión tienden a crecer con cada defecto encontrado, la automatización de pruebas se utiliza con frecuencia. A veces se realiza un análisis de impacto de cambios para determinar un subconjunto apropiado de pruebas ( análisis sin regresión ^{[ 4 ]} ).

A medida que el software se actualiza, se modifica o se reutiliza en un sistema modificado, es bastante común que aparezcan nuevos fallos o que reaparezcan fallos antiguos.

En ocasiones, la reaparición de un problema se produce porque una corrección se pierde debido a malas prácticas de control de versiones (o a un simple error humano en dicho control). A menudo, una corrección para un problema resulta frágil , ya que lo soluciona en el caso específico en el que se observó por primera vez, pero no en casos más generales que puedan surgir a lo largo de la vida útil del software. Con frecuencia, una corrección para un problema en un área provoca inadvertidamente un error de software en otra área.

Puede ocurrir que, al rediseñar una funcionalidad, algunos de los errores cometidos en su implementación original se repitan en el rediseño. En la mayoría de los casos de desarrollo de software, se considera una buena práctica de codificación , al localizar y corregir un error, registrar una prueba que lo revele y volver a ejecutarla periódicamente tras realizar cambios posteriores en el programa. ^{[ 5 ]}

Aunque esto puede hacerse mediante procedimientos de prueba manuales utilizando técnicas de programación, a menudo se hace mediante herramientas de prueba automatizadas . ^{[ 6 ]} Dicha suite de pruebas contiene herramientas de software que permiten al entorno de pruebas ejecutar automáticamente todos los casos de prueba de regresión ; muchos proyectos cuentan con sistemas de integración continua automatizados para volver a ejecutar todas las pruebas de regresión a intervalos específicos e informar de cualquier fallo (lo que podría implicar una regresión o una prueba desactualizada). ^{[ 7 ]}

Las estrategias habituales consisten en ejecutar dicho sistema después de cada compilación exitosa (para proyectos pequeños), todas las noches o una vez por semana. Estas estrategias pueden automatizarse mediante una herramienta externa. ^{[ 8 ]}

Las pruebas de regresión son una parte integral del método de desarrollo de software de programación extrema . ^{[ 9 ]} En este método, los documentos de diseño se reemplazan por pruebas exhaustivas, repetibles y automatizadas de todo el paquete de software en cada etapa del proceso de desarrollo . Las pruebas de regresión se realizan después de que concluyen las pruebas funcionales, para verificar que las demás funcionalidades funcionen correctamente.

En el mundo empresarial, las pruebas de regresión tradicionalmente las realizaba un equipo de aseguramiento de la calidad del software una vez que el equipo de desarrollo había finalizado su trabajo. Sin embargo, los defectos detectados en esta etapa son los más costosos de corregir. Este problema se está abordando con el auge de las pruebas unitarias . Si bien los desarrolladores siempre han escrito casos de prueba como parte del ciclo de desarrollo, estos casos de prueba generalmente han sido pruebas funcionales o pruebas unitarias que verifican únicamente los resultados previstos. Las pruebas realizadas por el desarrollador lo obligan a centrarse en las pruebas unitarias e incluir casos de prueba tanto positivos como negativos. ^{[ 10 ]}

Las distintas técnicas de pruebas de regresión son:

Las pruebas de regresión se realizan cuando se introducen cambios en la funcionalidad existente del software o cuando se corrige un error. Estas pruebas pueden llevarse a cabo mediante diversos enfoques; si se sigue un enfoque de prueba completa , se garantiza que los cambios realizados en el software no hayan afectado a las funcionalidades existentes, las cuales permanecen inalteradas. ^{[ 12 ]}

En el desarrollo ágil de software —donde los ciclos de vida del desarrollo de software son muy cortos, los recursos son escasos y los cambios en el software son muy frecuentes— las pruebas de regresión podrían introducir una gran cantidad de trabajo innecesario . ^{[ 12 ]}

En un entorno de desarrollo de software que tiende a utilizar componentes de caja negra de terceros, realizar pruebas de regresión puede ser complicado, ya que cualquier cambio en el componente de terceros puede interferir con el resto del sistema (y realizar pruebas de regresión en un componente de terceros es difícil porque es una entidad desconocida). ^{[ 12 ]}

Las pruebas de regresión se pueden utilizar no solo para comprobar la corrección de un programa, sino también, a menudo, para evaluar la calidad de su resultado. ^{[ 13 ]} Por ejemplo, en el diseño de un compilador , las pruebas de regresión podrían controlar el tamaño del código y el tiempo que tarda en compilarse y ejecutarse el conjunto de pruebas.

Además, como consecuencia de la introducción de nuevos errores, el mantenimiento del programa requiere muchas más pruebas del sistema por cada instrucción escrita que cualquier otro tipo de programación. En teoría, después de cada corrección, se debe ejecutar todo el conjunto de casos de prueba previamente realizados en el sistema para asegurar que no haya sufrido daños ocultos. En la práctica, estas pruebas de regresión deben aproximarse a esta idea teórica, y resultan muy costosas.

Las pruebas de regresión pueden realizarse en cualquier nivel, desde pruebas unitarias hasta la integración del sistema . Las pruebas funcionales ponen a prueba el programa completo con diversas entradas. Estas pruebas suelen automatizarse debido a la necesidad de repetición y pueden realizarse con herramientas de prueba que no forman parte del conjunto del compilador. Las pruebas no funcionales evalúan aspectos como el rendimiento, la seguridad o la fiabilidad. La realización de pruebas de regresión no funcionales presenta desafíos adicionales. Por ejemplo, detectar cambios en el rendimiento suele ser estadísticamente complejo, ^{[ 14 ]} mientras que los problemas de seguridad suelen surgir de vulnerabilidades en el ecosistema del software en lugar de cambios individuales en el código. ^{[ 15 ]}