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
Top Related