Introducción al Testing: Realizar pruebas de regresión eficientes e inteligentes

En un equipo de QA, existen muchas pruebas a realizar, y una de ellas son las pruebas de regresión, unas pruebas no del todo complejas pero que realmente no llegamos a saber el valor que tienen y aportan.

El problema de estas pruebas, es cuando son redundantes y repetitivas, es decir, que no nos están aportando nada y que no amplían la cobertura de funcionalidad probada ni, a nivel de código, si se realizan con test de integración, la cobertura de código que se prueba hasta la fecha.

 

El valor de las pruebas de regresión, viene dada por ser inteligente al diseñarlas, y a una serie de pautas:

• Tiempo: Las pruebas de regresión deben de ser medibles en el tiempo, tenemos que tener en cuenta el tiempo en realizarlas (si fuese necesario, y no las hemos seleccionado ya anteriormente de nuestro plan de pruebas), cuando nos lleva ejecutarlas y si hablamos a nivel de código cuanto nos lleva mantenerlas. 

• Relevancia: Debemos de tener claro el propósito de la prueba y que es lo que va a realizar. Además, del resultado que nos aportará y cual es la funcionalidad que validad y su criticidad.

• Significado: La prueba de regresión debe de tener un significado propio, debe de cubrir una serie de pautas definidas anteriormente y nos debe de asegurar que lo que probamos, vale para mantener la calidad del proyecto.

De cara a saber el valor que nos aporta una prueba de regresión, debemos de tener claro cuanto nos lleva crearla, ejecutarla y mantenerla, y en base a eso, tenemos que saber que nos reporta y si la funcionalidad es crítica o no. En base a toda esta información, tenemos que saber si nos merece la pena el realizarlas o no.

Lo ideal, y a lo que tenemos que ir, es que estas pruebas de regresión sean automáticas, por lo tanto, tienen un coste “extra” que nos tiene que hacer pensar el valor que puedan aportar. Personalmente, creo que, invirtiendo lo que tengamos que invertir, las pruebas de regresión aportan un valor muy alto, pero siempre sabiendo que no debemos de duplicarlas al hacerlas automáticas y saber el tiempo que nos va a llevar hacer los scripts necesarios.

Las pruebas de regresión deben de ser “reutilizadas”, me explico: son pruebas que ya se han escrito y definido anteriormente en la fase de definición propia del plan de pruebas y que seleccionamos posteriormente porque sabemos que lo que prueban puede ser crítico o grave y se basan en la experiencia que puede tener la persona que prueba sobre el proyecto en concreto. En este sentido, las pruebas no nos restan tiempo, solo tenemos que contabilizar el tiempo de ejecución manual, el tiempo que nos lleva hacer los scripts para automatizarlas y el tiempo que nos lleva repasar los resultados de las pruebas y saber lo que está funcionando y lo que no.

Otra manera de ahorrar tiempo y costes, es el definir las pruebas antes de que se describa el plan de pruebas, utilizando BDD, de esta manera tendremos caminos ya cubiertos y reutilizando información valiosa a posterior.

Dependiendo de como estemos en el proyecto y lo holgado que tengamos nuestro tiempo, debemos de pensar en otra estrategia, el ejecutar todas las pruebas de regresión por cada entrega o valorar el ejecutar solamente un paquete que sepamos que puede romper lo que ya estaba funcionando. 

Personalmente, suelo ser de los que piensan que es mejor el ejecutar todo, pero si es cierto, que, en la mayoría de las ocasiones, nuestro tiempo es muy limitado y nos podemos encontrar con que nos pillamos los dedos y no nos da tiempo a una ejecución completa. Según la entrega realizada, tenemos que enfocarnos en saber cuales han sido los cambios y que impactos puede tener en el software que ya estaba subido y funcionando, confiando en que hemos identificado correctamente esto y ahorrando muchísimo tiempo que podemos dedicar a otras labores, quizá, más importantes.

A nivel de automatización, si la estrategia ha sido el que las pruebas de regresión estén automatizadas, debemos de saber que se debe de medir la cobertura de las mismas, ya que, si no, el beneficio de estas es más bien escaso. Si tenemos muchas pruebas de regresión en las que hemos invertido una gran cantidad de esfuerzo y tiempo en realizarlas, pero no sabemos la cobertura de las mismas, el valor que nos aporta baja exponencialmente, debemos de ser inteligentes a la hora de saber cuanto nos lleva mantenerlas, y sobre todo ejecutarlas y analizar sus resultados, proporcionándonos una seguridad en las entregas y abriendo posibles defectos regresivos que rompen lo que ya estaba funcionando.

Desde mi punto de vista, las pruebas de regresión son totalmente imprescindibles en los proyectos y con ellas, tanto si son manuales o automáticas, averiguaremos posibles desperfectos, cosas que han dejado de funcionar y, sobre todo, levantaremos riesgos tempranos antes de que se llegue a cliente y cualquier problema de este tipo, haga un ruido tremendo. A nadie nos gusta ver algo que funcionaba y de repente se rompe, por lo tanto, os puedo decir, que no dejéis de hacer pruebas de regresión de manera inteligente y sabiendo y valorando el tiempo que tengáis en el proyecto.