Las pruebas de regresión (raramente, pruebas de no regresión [1] ) consisten en volver a ejecutar pruebas funcionales y no funcionales para garantizar que el software desarrollado y probado previamente aún funcione como se espera después de un cambio. [2] Si no, eso se llamaría regresión .
Los cambios que pueden requerir pruebas de regresión incluyen correcciones de errores , mejoras de software, cambios de configuración e incluso sustitución de componentes electrónicos ( hardware ). [3] Como las suites de pruebas de regresión tienden a crecer con cada defecto encontrado, la automatización de pruebas se involucra con frecuencia. La excepción evidente son las pruebas de regresión de GUI , que normalmente deben ejecutarse manualmente. A veces se realiza un análisis de impacto de cambio para determinar un subconjunto apropiado de pruebas ( análisis sin regresión [4] ).
A medida que el software se actualiza o cambia, o se reutiliza en un objetivo modificado, es bastante común que surjan nuevas fallas y/o que vuelvan a surgir fallas antiguas.
A veces, la reaparición se produce porque se pierde una corrección debido a prácticas deficientes de control de revisión (o un simple error humano en el control de revisión). A menudo, una corrección de un problema será " frágil " en el sentido de que soluciona el problema en el caso específico en el que se observó por primera vez, pero no en casos más generales que pueden surgir durante la vida útil del software. Con frecuencia, una corrección de un problema en un área provoca inadvertidamente un error de software en otra área.
Puede suceder que cuando se rediseña una característica, algunos de los mismos errores que se cometieron en la implementación original de la característica también ocurran en el rediseño. En la mayoría de las situaciones de desarrollo de software, se considera una buena práctica de codificación , cuando se encuentra y se corrige un error, registrar una prueba que exponga el error y volver a ejecutar esa prueba regularmente después de cambios posteriores en el programa. [5]
Aunque esto se puede hacer a través de procedimientos de prueba manuales utilizando técnicas de programación, a menudo se hace utilizando herramientas de prueba automatizadas . [6] Este tipo de conjunto de pruebas contiene herramientas de software que permiten que el entorno de prueba ejecute todos los casos de prueba de regresión automáticamente; muchos proyectos tienen sistemas de integración continua automatizados para volver a ejecutar todas las pruebas de regresión a intervalos específicos e informar cualquier falla (que podría implicar una regresión o una prueba desactualizada). [7]
Las estrategias habituales son ejecutar un sistema de este tipo después de cada compilación exitosa (para proyectos pequeños), todas las noches o una vez a la semana. Estas estrategias se pueden automatizar mediante una herramienta externa.
Las pruebas de regresión son una parte integral del método de desarrollo de software de programación extrema . En este método, los documentos de diseño se reemplazan por pruebas exhaustivas, repetibles y automatizadas de todo el paquete de software a lo largo de cada etapa del proceso de desarrollo de software . Las pruebas de regresión se realizan una vez que se han concluido las pruebas funcionales, para verificar que las demás funcionalidades estén funcionando.
En el mundo corporativo, las pruebas de regresión las ha realizado tradicionalmente un equipo de control de calidad de software después de que el equipo de desarrollo ha completado el trabajo. Sin embargo, los defectos encontrados en esta etapa son los más costosos de solucionar. Este problema se está abordando con el auge de las pruebas unitarias . Aunque 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 solo los resultados previstos. Las pruebas para desarrolladores obligan a un desarrollador a centrarse en las pruebas unitarias e incluir casos de prueba tanto positivos como negativos. [8]
Las diversas técnicas de pruebas de regresión son:
Esta técnica verifica todos los casos de prueba del programa actual para comprobar su integridad. Aunque es costosa, ya que es necesario volver a ejecutar todos los casos, garantiza que no haya errores debido al código modificado. [9]
A diferencia de Retest all, esta técnica ejecuta una parte del conjunto de pruebas (debido al costo de Retest all) si el costo de seleccionar la parte del conjunto de pruebas es menor que la técnica Retest all. [9]
Priorizar los casos de prueba de manera de aumentar la tasa de detección de fallas de un conjunto de pruebas. Las técnicas de priorización de casos de prueba programan los casos de prueba de manera que los casos de prueba con mayor prioridad se ejecuten antes que los casos de prueba con menor prioridad. [9]
Esta técnica es un híbrido de selección de pruebas de regresión y priorización de casos de prueba. [9]
Las pruebas de regresión se realizan cuando se realizan cambios en la funcionalidad existente del software o si se corrige un error en el software. Las pruebas de regresión se pueden lograr mediante múltiples enfoques; si se sigue un enfoque de prueba total , se brinda certeza de que los cambios realizados en el software no han afectado las funcionalidades existentes, que permanecen inalteradas. [10]
En el desarrollo de software ágil , 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 pueden introducir una gran cantidad de sobrecarga innecesaria . [10]
En un entorno de desarrollo de software que tiende a utilizar componentes de caja negra de un tercero, 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). [10]
Las pruebas de regresión se pueden utilizar no solo para probar la corrección de un programa, sino también a menudo para rastrear la calidad de su salida. [11] Por ejemplo, en el diseño de un compilador , las pruebas de regresión podrían rastrear el tamaño del código y el tiempo que lleva compilar y ejecutar los casos del conjunto de pruebas.
Además, como consecuencia de la introducción de nuevos errores, el mantenimiento de un programa requiere muchas más pruebas del sistema por cada instrucción escrita que cualquier otro programa. En teoría, después de cada corrección, se debe ejecutar todo el lote de casos de prueba ejecutados previamente contra el sistema para asegurarse de que no haya sufrido daños de forma oculta. En la práctica, estas pruebas de regresión deben aproximarse a esta idea teórica y son muy costosas.
— Fred Brooks , El mes mítico del hombre , pág. 122
Las pruebas de regresión se pueden clasificar en líneas generales como pruebas funcionales o pruebas unitarias . Las pruebas funcionales ejercitan el programa completo con varias entradas. Las pruebas unitarias ejercitan funciones individuales, subrutinas o métodos de objetos. Tanto las herramientas de pruebas funcionales como las herramientas de pruebas unitarias tienden a estar automatizadas y, a menudo, son productos de terceros que no forman parte del conjunto de compiladores. Una prueba funcional puede ser una serie de entradas de programa programadas, posiblemente incluso involucrando un mecanismo automatizado para controlar los movimientos y clics del mouse. Una prueba unitaria puede ser un conjunto de funciones separadas dentro del código mismo o una capa de controlador que se vincula al código sin alterar el código que se está probando.
Las actividades de prueba que se centran en problemas de regresión se denominan pruebas de (no) regresión. Por lo general, se omite la palabra "no"