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.
0 Comentarios