Pruebas De Regresion

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 <> • [ Johanna Rojas y Emilio Barrios]” Pruebas de Regresión”, 2007 <
ruebas%20de%20software/node57.html>> • [Desconocido]”Zeta Test ”, 2011 << http://www.zeta-test.com/screenshots.html>>