Las pruebas de regresión son de vital importancia para el mantenimiento con calidad de nuestro sistema de información. Gracias a ellas aseguramos el correcto funcionamiento de la parte más «core» del producto en varias circunstancias. ¿Sabes por qué? ¿Sabes que son esas pruebas de regresión? ¿Y por qué no debes olvidar incluirlas en tu plan de pruebas? Te responderé estas preguntas dentro del contexto de pruebas a sistema web.
Índice de contenidos
¿Qué son las pruebas de regresión?
Estas pruebas son un conjunto de casos que revisan el correcto funcionamiento o estado de un conjunto de características o funcionalidades del sistema que han podido ser afectadas por cambios recientes. Estas modificaciones no tienen por qué haber sido sobre el área especifica definida en la prueba. Sin embargo han podido ser impactadas con defectos debido a la actualización de código o configuraciones relacionadas.
¿En qué circunstancia son necesarias las pruebas de regresión?
Hay varias circunstancias en las que son necesarias estas pruebas.
Por ejemplo, tras realizar una actualización de código o de la versión del CMS sobre la que está soportada la aplicación. Por mucho que revisemos la documentación, y se le ponga cuidado y esmero en aplicar esa actualización, siempre puede haber algo que se nos escape.
Otra circunstancia es cuando se implanta un evolutivo relacionado o no. Se realizan modificaciones sobre configuraciones o partes de código que pueden estar relacionadas, o pueden impactar de forma negativa sobre otra funcionalidad. Inicialmente no sebe estar impactada, pero no está de más realizar una mínima regresión para asegurarnos que todo está bien.
Y por último, tras actualizaciones de los soportes (sistemas operativos, entornos, etc) donde están ejecutándose estas aplicaciones. Si se ha realizado una actualización en los servidores utilizados, puede dañarse partes del software por alguna actualización no soportada.
¿Por qué debes incluir pruebas de regresión en tu plan de pruebas?
Como hemos comentado anteriormente, hay muchas circunstancias que pueden provocar daños colaterales en el software. Por ello, es recomendable incluir este conjunto de casos de pruebas de regresión para verificar que no se ha roto algo que funcionaba correctamente de forma previa.
Nos encontraremos en dos circunstancias similares. Por un lado tenemos que incluir un conjunto de pruebas de regresión al incorporar un evolutivo, y por otro lado debemos tener listo un plan de regresión con casos core para verificar el correcto funcionamiento de las funcionalidades principales del sistema para una modificación que impacte de forma global.
¿Qué casos se debe incluir en ese plan de pruebas?
Diferenciando entre las dos opciones anteriores, es recoemndable incluir.
Conjunto de casos de regresión
- Casos para probar funcionalidades relacionadas
- Casos para probar funcionalidades NO relacionadas
- Casos para probar validaciones de campos
Plan de pruebas de regresión core
- Casos para probar las funcionalidades más utilizadas
- Casos para probar las características o funcionamiento bajo normativa
- Casos para probar puntos que han fallado previamente con otras versiones del software
Planifica adecuadamente tu plan de regresión
En cualquier caso es importante tener bien planificada tus pruebas de regresión. Volviendo a las dos opciones en las que se ejecutarán:
Primero nos centraremos en las pruebas de regresión incluidas en las actualizaciones producidas por un evolutivo o correctivo. Estás se deben incluir dentro de uno o de un par de ciclos, priorizadas como corresponde (prioridades alta, media y baja) y planificadas para ejecutarse en las fechas finales del ciclo de pruebas, como parte importante, pero no urgente.
En segundo lugar deben planificarse la ejecución de nuestro plan de pruebas de regresión core cuando se realizan las modificaciones de entorno o sistema operativo. En estos casos, se suele programar tanto las actualizaciones, como las pruebas de regresión en horarios de poca afluencia de usuario. Además se tienen preparados el juego de datos de ejecución necesarios. Por otro lado se tienen previstos, y acotados los tiempos para su ejecución, ya que se han realizado las mismas acciones en entornos pre-productivos. En esta situación es importante, de igual forma tener priorizados los casos de prueba y planificados su orden de ejecución en función de la criticidad.
Las grandes candidatas a la automatización
Como comenté en el post «10 Tips para la automatización de pruebas de QA«, las pruebas de regresión son uno de los casos de prueba candidatos a la automatización. Nos encontramos con casos que se van a ejecutar de forma frecuente: estás pruebas son muy repetitivas. Además, sobre ellas no será necesario realizar grandes tareas de mantenimiento (ya que sufrirán pocos cambios, por ser funcionalidades core). En conclusión, ahorraremos costes en nuestra organización y evitaremos errores humanos al poder ejecutar esos planes de prueba sin la necesidad de ejecutarse de forma manual.
Conclusión: Apuesta por las pruebas de regresión
Dale la importancia que requieren a las pruebas de regresión. Gracias a ella aseguramos la calidad de nuestro sistema, evitamos sorpresas en producción y mantenemos una buena imagen de la organización. Es necesario no menospreciar este set de prueba, y en la medida de lo posible que se encarguen de su elaboración (el listado de los casos principales) el equipo completo, tanto desarrollo como testing. De esta forma tendremos una visión global y enriquecida de la situación real. Y si además, entra en la ecuación el cliente y aporta su punto de vista, mejor que mejor.
¿Qué te ha parecido el post? ¿Tienes algo que aportar? Déjame tu comentario y lo comentamos. También puedes suscribirte al blog para estar al tanto sobre todas las novedades.
