Patricia Coronel

Agenda Definición

Objetivos

Selección de las pruebas

Cuando?

Cuando automatizar?

Tres pasos para un testing de regresión sólido

Consideraciones Finales

Conclusión

Regression testing

01/09/2009 2Patricia Coronel

Definición“Es la ejecución de un conjunto de pruebas que serealiza sobre el software en cada nueva iteración orelease para asegurar que todos los erroresreportados han sido resueltos, errores anteriores nohan vuelto a surgir, las nuevas funcionalidadesresponden según lo especificado después de suintegración y, sobre todo, que las funcionalidadesanteriores no han sido afectadas con la introduccióndel nuevo código y aún funcionan de acuerdo a susespecificaciones funcionales.”

Regression testing

01/09/2009 3Patricia Coronel

Objetivos Identificar defectos inesperados, probar que la

resolución de errores no ha generado nuevosdefectos.

Proveer la seguridad de que las modificaciones oadiciones realizadas al código son seguras y noson propensas a romper las funcionalidadesexistentes en la aplicación.

Realizar el seguimiento de la calidad delproducto durante su evolución.

Regression testing

01/09/2009 4Patricia Coronel

Selección de las pruebasLas pruebas que deben incluirse son aquellas que verifican:

Código crítico del sistema. Código que implementa las funcionalidades mas utilizadas. Código nuevo o modificado. Componentes que durante la última prueba de regresión produjeron defectos. Componentes del sistema que después de las pruebas de regresión produjeron

defectos (reportadas por el cliente, lo cual signifca que las pruebas del softwareno fueron adecuadas en un primer lugar).

Tambien deben incluirse aquellas que:

Verifican la resolución de defectos o modificaciones. Tienen dependencia funcional, condicional o de ejecución compartida con otro

componente, sistema o módulo. Tienen una dependencia de entrada o salida que es compartida con otra parte

del código.

Regression testing

01/09/2009 5Patricia Coronel

Cuando?Las pruebas de regresión deben comenzar cuando:

Se ha desarrollado una nueva subclase

Se ha cambiado una superclase

Una clase del servidor ha cambiado

Se ha resuelto un defecto

Se ha generado un nuevo build del sistema

Se ha generado un nuevo incremento para pruebas de integración o de sistema

El sistema se encuentra estable y se ha generado el build para el release final

Regression testing

01/09/2009 6Patricia Coronel

Cuando automatizar?Las pruebas de regresión deben automatizarse cuando:

Deben ejecutarse con cada build de la aplicación, consumen mucho tiempo y hacen uso inconsistente de los recursos humanos

Requieren el uso de muchos valores con múltiplesdatos para la misma acción.

Las pruebas requieren de información detallada de sistemas internos, tales como SQL y atributos de la GUI.

Hay una necesidad de estresar el sistema para medir el rendimiento.

Regression testing

01/09/2009 7Patricia Coronel

Tres pasos para un testing de regresión sólido

Volver a probar un defecto siguiendo tal cualfueron reportados los pasos de reproducción.

Pensar que estaba haciendo el usuario cuandoreportó el bug y probar en base a esa actividad

Trabajar junto con Desarrollo para comprender elcambio desde la perspectiva del código.

Regression testing

01/09/2009 8Patricia Coronel

Consideraciones finales Cuando se descubren defectos inesperados, se deben crear

nuevas pruebas de regresión

Se debe disponer y mantener una librería con pruebas de regresión a medida que el softare evoluciona con cadaincremento de funcionalidad.

Debe haber una metodología para aislar las pruebas de regresiónque se focalizan en ciertas áreas del software.

Si la arquitectura de un sistema se cambia por completo, se debe ejecutar una prueba de regresión por completo.

Se debe considerar el testing automatizado con herramientas de captura y playback.

Regression testing

01/09/2009 9Patricia Coronel

Conclusión

“Una buena prueba de regresión le da alcliente la confianza necesaria paracambiar su producto o entorno delproducto”

Regression testing

01/09/2009 10Patricia Coronel