Pruebas de Regresión

Es cualquier tipo de pruebas de software que intentan descubrir las causas de nu

evos errores (bugs), carencias de funcionalidad, o divergencias funcionales con
respecto al comportamiento esperado del software, inducidos por cambios reciente
mente realizados en partes de la aplicación que anteriormente al citado cambio no
eran propensas a este tipo de error.
Esto implica que el error tratado se reproduce como consecuencia inesperada del
citado cambio en el programa.
Este tipo de cambio puede ser debido a prácticas no adecuadas de control de versio
nes, falta de consideración acerca del ámbito o contexto de producción final y extensi
bilidad del error que fue corregido (fragilidad de la corrección), o simplemente u
na consecuencia del rediseño de la aplicación.
Por lo tanto, en la mayoría de las situaciones del desarrollo de software se consi
dera una buena práctica que cuando se localiza y corrige un bug, se grabe una prue
ba que exponga el bug y se vuelvan a probar regularmente después de los cambios su
bsiguientes que experimente el programa.
Herramientas de Software
Permiten detectar este tipo de errores de manera parcial o totalmente automatiza
da, la práctica habitual en programación extrema es que este tipo de pruebas se ejec
uten en cada uno de los pasos del ciclo de vida del desarrollo del software.
Herramienta de Software: Zeta Test
Ambiente de administración de pruebas integrado que le permite ejecutar pruebas de
caja-negra, caja-blanca, pruebas de regresión o pruebas de administración de cambio
de programas de aplicación.
Zeta Test le ayuda a planificar, ejecutar, registrar, verificar y documentar las
pruebas, para luego evaluar los resultados de las pruebas.
Objetivo
El objetivo de las pruebas de regresión es eliminar el efecto onda, es decir, comp
robar que los cambios sobre un componente de un sistema de información, no introdu
cen un comportamiento no deseado o errores adicionales en otros componentes no m
odificados.
¿Cuándo deben realizarse las Pruebas de Regresión?
No es suficiente probar sólo los componentes modificados o añadidos, o las funciones
que en ellos se realizan, sino que también es necesario controlar que las modific
aciones no produzcan efectos negativos sobre el mismo u otros componentes.
Las pruebas de regresión pueden incluir:
• La repetición de los casos de pruebas que se han realizado anteriormente y están di
ectamente relacionados con la parte del sistema modificada.
• La revisión de los procedimientos manuales preparados antes del cambio, para asegu
rar que permanecen correctamente.
La obtención impresa del diccionario de datos de forma que se compruebe que los el
ementos de datos que han sufrido algún cambio son correctos.
Tipos de regresión
Clasificación de ámbito:
• Local: Los cambios introducen nuevos errores.
• Desenmascarada: Los cambios revelan errores previos.
• Remota: Los cambios vinculan alguna otra parte del programa (módulo) e introducen
errores en ella.
Clasificación temporal
• Nueva característica: Los cambios realizados con respecto a nuevas funcionalidades
en la versión introducen errores en otras novedades en la misma versión del softwar
e.
• Característica preexistente: Los cambios realizados con respecto a nuevas funciona
lidades introducen errores en previas versiones.
¿Cómo mitigar los riesgos?
• Repetición completa y habitual de la batería de pruebas, manual o mediante automati
ación.
• Repetición parcial basada en trazabilidad y análisis de riesgos.
• Pruebas de cliente o usuario:
Beta: Distribución a clientes potenciales y actuales de versiones beta.
Pilot : Distribución a un subconjunto bien definido y localizado.
Paralela: Simultaneando uso de ambos sistemas.
• Probar nuevas funciones a menudo cubre las funciones existentes. Cuantas más nueva
s características haya en un release, habrá mayor nivel de pruebas de regresión "accid
ental".
Usos
Las Pruebas de Regresión pueden usarse no solo para probar la corrección de un progr
ama, sino a menudo usarse para rastrear la calidad de su salida.

Ejemplo
Por ejemplo en el diseño de un compilador, las pruebas de regresión deben rastrear e
l tamaño del código, tiempo de simulación, y el tiempo de compilación de las suites de p
rueba. Cuando quiera que aparece un nuevo build, el proceso de regresión aparece.
Citas
"También como consecuencia de la introducción de nuevos bugs, el mantenimiento del p
rograma necesita más pruebas del sistema por sentencia escrita que cualquier otra
programación. En teoría, después de cada corrección uno debe ejecutar el batch completo
de casos de prueba antes de ejecutar contra el sistema, para asegurarse de que n
o ha sido dañado de forma oscura. En la práctica, tales pruebas de regresión deben apr
oximarse a esta idea teórica, y es muy costoso." por Fred Brooks, The Mythical Man
Month.
Referencias
• [Desconocido]” Pruebas de regresión”, 11 de Junio de 2010 <<http://es.wikipedia.org
ki/Pruebas_de_regresi%C3%B3n>>
• [ Johanna Rojas y Emilio Barrios]” Pruebas de Regresión”, 2007 <<http://gemini.udis
tal.edu.co/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pruebas/HTML%20-%20P
ruebas%20de%20software/node57.html>>
• [Desconocido]”Zeta Test ”, 2011 << http://www.zeta-test.com/screenshots.html>>