Patricia Coronel
Regression testing Agenda 01/09/2009
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 Patricia Coronel
2
Regression testing Definición “Es la ejecución de un conjunto de pruebas que se realiza sobre el software en cada nueva iteración o release para asegurar que todos los errores reportados han sido resueltos, errores anteriores no han vuelto a surgir, las nuevas funcionalidades responden según lo especificado después de su integración y, sobre todo, que las funcionalidades anteriores no han sido afectadas con la introducción del nuevo código y aún funcionan de acuerdo a sus especificaciones funcionales.” 01/09/2009
Patricia Coronel
3
Regression testing Objetivos
Identificar defectos inesperados, probar que la resolución de errores no ha generado nuevos defectos. Proveer la seguridad de que las modificaciones o adiciones realizadas al código son seguras y no son propensas a romper las funcionalidades existentes en la aplicación. Realizar el seguimiento de la calidad del producto durante su evolución.
01/09/2009
Patricia Coronel
4
Regression testing Selección de las pruebas Las 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 software no 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. 01/09/2009
Patricia Coronel
5
Regression testing 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 01/09/2009
Patricia Coronel
6
Regression testing 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últiples datos 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. 01/09/2009
Patricia Coronel
7
Regression testing Tres pasos para un testing de regresión sólido
Volver a probar un defecto siguiendo tal cual fueron reportados los pasos de reproducción.
Pensar que estaba haciendo el usuario cuando reportó el bug y probar en base a esa actividad
Trabajar junto con Desarrollo para comprender el cambio desde la perspectiva del código.
01/09/2009
Patricia Coronel
8
Regression testing 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 cada incremento de funcionalidad.
Debe haber una metodología para aislar las pruebas de regresión
que 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.
01/09/2009
Patricia Coronel
9
Regression testing Conclusión “Una buena prueba de regresión le da al cliente la confianza necesaria para cambiar su producto o entorno del producto”
01/09/2009
Patricia Coronel
10