Pruebas de regresión. O cómo evitar que los fallos que se habían arreglado en el software vuelvan a aparecer.

Tenemos que tener presente que cualquier cambio en el código de una aplicación, por pequeño e inofensivo que parezca, puede tener consecuencias inesperadas.
Un pequeño cambio puede “romper” partes del código que antes funcionaba y que parecía que no tenían relación alguna con la modificación que hemos realizado. Incluso puede hacer que errores que ya hemos solucionado vuelvan a aparecer, por mencionar algunos ejemplos.
Por ello, a probar el software para asegurarnos de que un cambio, o la incorporación de una nueva funcionalidad no ha “roto” lo que ya había antes, se le llama hacer pruebas de regresión.
Cuando hacemos pruebas de regresión, estamos comprobando que el código que hemos modificado se comporta como queremos, y que el cambio no ha causado otros problemas en otros sitios del código, que funcionaban correctamente la última vez que los probamos.
Volviendo a ejecutar las pruebas con las que detectamos los errores que ya solucionamos, podemos tener una cierta seguridad de que nuevos cambios en el software no provocan una regresión, es decir, no hacen que componentes que antes funcionaban dejen de hacerlo ni provocan que resurjan errores que parecían que se habían eliminado.
Estas pruebas de regresión se pueden hacer de forma manual, o automatizada, pero en muchos casos se suelen automatizar, para ejecutarse frecuentemente.
Las pruebas de regresión suelen tener un papel importante en el proceso de integración continua (aquí te dejo el post de La integración continua y el «smoke test»), y suelen ser lanzados por servidores de integración continua como Jenkins (recuerda ¿Qué es Jenkins? Explicado en menos de 10 min para quienes no lo conocen de nada ).

¿Cómo se hacen las pruebas de regresión?

Las pruebas de regresión no necesitan ser escritas como tal, sino que se pueden crear a partir de pruebas que hemos ido elaborando durante el desarrollo.
La idea es que cada vez que modificas el código fuente, ejecutes una selección de pruebas relevantes que ya tenías para ver si todo funciona como debería.
Pruebas funcionales, pruebas unitarias, pruebas de integración (cualquier cosa que haya verificado durante el proceso de desarrollo que ciertos componentes del software funcionan como deberían) pueden actuar como pruebas de regresión.
Por ejemplo, podríamos aprovechar las pruebas unitarias de JUnit que realizan los desarrolladores, e incluirlas como pruebas de regresión automatizadas.
No obstante, merece la pena destacar que hacer pruebas de regresión no tiene por qué significar hacer pruebas unitarias. Otro tipo de pruebas que sirvan para lo que he comentado a lo largo del post, pueden utilizarse como pruebas de regresión.
Además, a medida que avanza el proyecto, la batería de pruebas de regresión puede hacerse cada vez más y más grande y consumir mucho tiempo. Incluso, puede que tests que antes habíamos incluido como pruebas de regresión ya no apliquen, o no sean tan relevantes a medida que evoluciona el software.
Puede llegar un punto en el que ejecutar toda la batería de pruebas que ya tengamos sea inviable.
Por lo tanto, tenemos que seleccionar bien las pruebas que van a actuar como pruebas de regresión, pensando qué queremos demostrar con ellas.
De nada nos sirve tener una batería de pruebas de regresión automáticas que se ejecuten cada cierto tiempo, si realmente no prueban nada, no demuestran que los errores que se han cometido antes no vuelvan a aparecer.
Cuando terminamos de solucionar defectos en el software, deberemos realizar un análisis de impacto y determinar qué pruebas son las más relevantes, las que realmente nos van a aportar algún valor si se ejecutan periódicamente, para incluirlas como pruebas de regresión.
Por otra parte, la batería de pruebas de regresión no se mantiene igual durante todo el desarrollo. A medida que evolucione el software tendremos que ir cambiándolas: desechar las que ya no nos aporten valor, incluir nuevas etc.

¿Pruebas de regresión=pruebas automatizadas=fuera las pruebas manuales?

Este es un punto que merece la pena aclarar. En primer lugar, el concepto de pruebas de regresión como tal, no implica que tengan que ser pruebas automatizadas, solo que es algo que se tiende a realizar, para ejecutarlas frecuentemente.
Por otra parte, el tener pruebas de regresión no es una garantía de que todo funciona perfectamente. Digamos que este tipo de pruebas son pruebas que ya hemos ejecutado antes, y que ejecutamos periódicamente después de algún cambio, para asegurarnos de que errores que ya detectamos antes y solucionamos no vuelvan a aparecer. Y esto es una pequeña parte de todos los riesgos, de todos los errores que puedan aparecer en el software.
Michael Bolton utiliza una metáfora que me encanta para explicar esto, compara los riesgos que existen en una aplicación con un iceberg.
Captura de pantalla 2014-06-17 a las 16.06.28
Normalmente lo que hemos probado, lo que conocemos, es una pequeña parte (la punta del iceberg que se muestra en la superficie del océano) de todos los riesgos que puede haber en el software, de todas las casuísticas o pruebas que podemos hacer sobre nuestro software.
Por lo tanto, estas pruebas de regresión, forman parte de esta punta del iceberg. Es necesario realizar este tipo de pruebas junto con otro tipo, incluso de forma complementaria a las pruebas manuales, pensadas, planificadas, para abarcar un poco más y descubrir más errores, conocer parte del resto del iceberg.
No obstante, son chequeos que no cuestan nada realizar, y pueden ayudarnos a minimizar ciertos riesgos.

Javier Garzás

4 comentarios en “Pruebas de regresión. O cómo evitar que los fallos que se habían arreglado en el software vuelvan a aparecer.”

  1. Erick J. Guerrero

    Hola María,
    Buen Blog, pero no me queda claro algo, que quisiste decir con esto:
    «Volviendo a ejecutar las pruebas con las que detectamos los errores que ya solucionamos, podemos tener una cierta seguridad de que nuevos cambios en el software no provocan una regresión, es decir, no hacen que componentes que antes funcionaban dejen de hacerlo ni provocan que resurjan errores que parecían que se habían eliminado.»
    Si ejecuto las pruebas nuevamente, ¿Estoy asegurando en cierta forma de no hacer una regression?

    1. A pesar que el texto parece claro, te lo explico desde mi punto de vista: quiere decir que si vuelves a ejecutar un caso, que antes fallaba, en una nueva versión donde se ha corregido el error éste debería pasar la prueba con lo que nos aseguramos no tener que volver a modificar una versión atrás para arreglar el mismo fallo/error.

  2. Hola Maria,
    tengo una consulta sobre la aplicacion de regresion testing,
    actualmente tengo una version 8 de una aplicacion x, y se me ha asignado la revision de un bug que fue encontrada en una version anterior que es la 7, debo comprobar que en verdad es un bug pero no puedo reproducirlo debido a que en la version 8 ese issue ya esta solucionado.
    y tampoco tengo accesso al codigo y mucho menos a unit tests
    el issue que estoy tratando de verificar es de instalacion.
    todo el material que tengo es de estudio obviamente y no puedo conseguir otras versiones, mi consulta es:
    que tengo que hacer en este tipo de situaciones? o,
    como debo aplicar un regresion testing si no tengo la version en la que el issue puede ser reproducible y verificable?
    Saludos
    Jorge

  3. Cómo puedo mejorar la pruebas funcionales si al realizar el mismo procedimiento y pasarlo a producción se origina otro error. Automatizando esto disminuiría?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba