¿Por qué un test de Regresión?

Todos aquellos que, de un modo u otro, pasamos nuestra vida laboral relacionados con el mundo de la calidad del software, nos hemos visto en la encrucijada de explicarle a algún conocido profano en la materia qué es el fenómeno de la regresión.

Para muchos, regresión se referirá al concepto freudiano. Para otros, será una medida estadística. Pero para los que estamos dentro del ecosistema del Quality Assurance, la regresión constituye uno de los hechos más frecuentes, y muchas veces más dañinos, para nuestros sistemas informáticos.

Per, ¿qué es la regresión? Una regresión se produce cuando, tras la implementación de un cambio, un software falla en alguna de las partes que han permanecido inalterables.

El profano en la materia, una vez reciba esta explicación, pasará del total desconocimiento a la más absoluta de las sorpresas. ¿Cómo es posible que algo empiece a fallar sino ha sufrido cambio alguno? Es aquí donde podemos decir, sin temor a equivocarnos, que si categorizáramos los errores en función de su causa, podríamos agrupar muchos de ellos en errores producidos por una regresión en nuestro sistema.

Por este motivo, los tests de regresión son una de las piezas esenciales dentro de cualquier ciclo vida de desarrollo de software, y por ende, se transforman en una de las tareas principales de cualquier persona dedicada al QA, así como la selección de su estrategia de pruebas, uno de los retos más complejos y recurrentes para managers a cargo de la gestión del día a día.

Para entender el porqué de dicha complejidad, volvamos a la propia definición del concepto de regresión que hemos mencionado anteriormente, pero centrándonos en dos partes clave:

• “Implementación de un cambio”
  • ¿Qué constituye una variación en nuestro software? Toda aquella modificación, por mínima que sea, necesitará, ya sea en mayor o menor medida, de pruebas de regresión. Debemos tener en cuenta, además, que un cambio puede ir desde cualquier adición de funcionalidad, hasta una pequeña actualización de configuración.
  • Asimismo, cabe decir que el tamaño de la alteración realizada no tiene porque estar directamente relacionada con la cantidad de Regression Testing a realizar. Al fin y al cabo, la “cantidad” estará íntimamente relacionada con otro de los conceptos claves del mundo de la calidad: el riesgo. O lo que es lo mismo, a mayor riesgo (y definir en si el propio riesgo nos daría para una vasta discusión), mayor necesidad de ejecutar tests de regresión. Y como muchos de vosotros sabréis, el riesgo puede revelarse en el más pequeño e insospechado de los cambios.
• “Partes que han permanecido inalterables”
  • Un análisis pausado de esta parte de la definición nos hace entender el gran océano que pueden resultar las pruebas de regresión. Las porciones del sistema que no cambian (teóricamente), constituyen la mayoría de veces un conjunto increíblemente grande del total.
  • Esto hace que el catálogo de tests de regresión se transforme en un gigante difícil de manejar. En un mundo claramente dominado por la tendencia a la reducción en los tiempos de desarrollo, el esfuerzo disponible para realizar pruebas se ve irremediablemente reducido, transformando a la estrategia y planificación de pruebas, en uno de los mayores retos de la industria de la calidad del software.
  • Por último, conviene no olvidar que el catálogo de pruebas de regresión, por naturaleza, va a tender a crecer, ya que todo aquello que consideramos cambio (ya sea nueva funcionalidad, mejora o corrección), deberá pasar, de un modo u otro, a formar parte de nuestra regresión, una vez esa modificación ya no sea tal (p.ej. cuando el cambio pasa a formar parte del sistema en producción).

Todo lo que hemos visto hasta ahora nos permite radicar en la importancia de la realización de pruebas de regresión. Como hemos mencionado anteriormente, son tests que deben ser realizados tras la implementación de cualquier cambio. Sin embargo, el momento y la frecuencia exactos de su ejecución dependerán de muy distintos factores que recaerán en la selección de una correcta estrategia de pruebas, y que trataremos en artículos futuros.

Isaac Álvarez Diz
Innovation Lead | Digital Assurance & Testing | SOGETI ESPAÑA