Pruebas de regresión

Prueba de regresión (en raras ocasiones, prueba de no regresión) consiste en volver a ejecutar pruebas funcionales y no funcionales para garantizar que el software desarrollado y probado previamente siga funcionando como se esperaba después un cambio. Si no, eso se llamarí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 sustitución de componentes electrónicos. Dado que los conjuntos de pruebas de regresión tienden a crecer con cada defecto encontrado, la automatización de pruebas suele estar involucrada. A veces, se realiza un análisis de impacto del cambio para determinar un subconjunto apropiado de pruebas (análisis de no regresión).

Antecedentes

A medida que el software se actualiza o cambia, o se reutiliza en un objetivo modificado, la aparición de nuevas fallas y/o la reaparición de fallas antiguas es bastante común.

A veces, la reaparición se produce porque se pierde una solución debido a prácticas de control de revisión deficientes (o un simple error humano en el control de revisión). A menudo, una solución para un problema será "frágil" ya que soluciona el problema en el caso específico en el que se observó por primera vez, pero no en los casos más generales que pueden surgir durante la vida útil del software. Con frecuencia, una solución para un problema en un área provoca inadvertidamente un error de software en otra área.

Por último, puede suceder que, cuando se rediseña alguna función, se cometan en el rediseño algunos de los mismos errores que se cometieron en la implementación original de la función. Por lo tanto, en la mayoría de las situaciones de desarrollo de software, se considera una buena práctica de codificación, cuando se localiza y corrige un error, registrar una prueba que expone el error y volver a ejecutar esa prueba regularmente después de cambios posteriores en el programa.

Aunque esto se puede hacer a través de procedimientos de prueba manuales usando técnicas de programación, a menudo se hace usando herramientas de prueba automatizadas. Dicho 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; algunos proyectos incluso configuran sistemas automatizados para volver a ejecutar todas las pruebas de regresión a intervalos específicos e informar cualquier falla (lo que podría implicar una regresión o una prueba desactualizada).

Las estrategias comunes son ejecutar dicho sistema después de cada compilación exitosa (para proyectos pequeños), todas las noches o una vez a la semana. Esas estrategias pueden ser automatizadas por 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 concluidas las pruebas funcionales, para verificar que las otras funcionalidades están funcionando.

En el mundo empresarial, las pruebas de regresión las ha realizado tradicionalmente un equipo de control de calidad del software después de que el equipo de desarrollo haya completado el trabajo. Sin embargo, los defectos encontrados en esta etapa son los más costosos de reparar. Este problema está siendo abordado por 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 de desarrollador obligan a un desarrollador a centrarse en las pruebas unitarias e incluir casos de prueba tanto positivos como negativos.

Técnicas

Las diversas técnicas de prueba de regresión son:

Volver a probar todo

Esta técnica verifica todos los casos de prueba en el programa actual para verificar su integridad. Aunque es costoso ya que necesita volver a ejecutar todos los casos, asegura que no haya errores debido al código modificado.

Selección de prueba de regresión

A diferencia de Volver a probar todo, esta técnica ejecuta una parte del conjunto de pruebas (debido al costo de volver a probar todo) si el costo de seleccionar la parte del conjunto de pruebas es menor que la técnica Volver a probar todo.

Priorización de casos de prueba

Dar prioridad a los casos de prueba para 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 para que los casos de prueba que tienen una prioridad más alta se ejecuten antes que los casos de prueba que tienen una prioridad más baja.

Tipos de priorización de casos de prueba

• Priorización general – priorizar casos de prueba que serán beneficiosos en versiones posteriores
• Priorización específica de la versión – Priorizar casos de prueba con respecto a una versión particular del software.

Híbrida

Esta técnica es un híbrido de selección de pruebas de regresión y priorización de casos de prueba.

Ventajas y desventajas

La prueba de regresión se realiza cuando se realizan cambios en la funcionalidad existente del software o si hay una corrección de errores en el software. Las pruebas de regresión se pueden lograr a través de múltiples enfoques; si se sigue un enfoque de probar todo, proporciona la certeza de que los cambios realizados en el software no han afectado las funcionalidades existentes, que permanecen inalteradas.

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 generar muchos gastos generales innecesarios.

En un entorno de desarrollo de software que tiende a usar 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).

Usos

Las pruebas de regresión se pueden usar no solo para probar la corrección de un programa, sino también para rastrear la calidad de su salida. 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.

También como consecuencia de la introducción de nuevos errores, el mantenimiento del programa requiere mucho más pruebas del sistema por declaración escrita que cualquier otra programación. Teóricamente, después de cada solución, se debe ejecutar todo el lote de casos de prueba previamente corren contra el sistema para asegurarse de que no se ha dañado de manera oscura. En la práctica, tal pruebas de regresión de hecho debe aproximar esta idea teórica, y es muy costoso.

—Fred Brooks, El Mes del Hombre Místico, pág. 122

Las pruebas de regresión se pueden clasificar en términos 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 de la suite del compilador. Una prueba funcional puede ser una serie de secuencias de comandos de entradas de programa, posiblemente incluso involucrando un mecanismo automatizado para controlar los movimientos del mouse y los clics. Una prueba unitaria puede ser un conjunto de funciones separadas dentro del propio código o una capa de controlador que se vincula al código sin alterar el código que se está probando.