Las pruebas de regresión se realizan para descubrir defectos que se producen con un cambio del sistema, una subida errónea o algo que no se ha tenido en cuenta.
En muchos casos y según la teoría de ciertos libros, las pruebas de regresión son casos que se realizan basados en un defecto y que en cada sprint probamos viendo que no vuelve a suceder. Yo, en los proyectos donde he trabajado, siempre doy un paso más, con los casos de prueba de alguna funcionalidad, siempre marco uno o dos (los básicos) para agregarlos a estas pruebas de regresión. Así tenemos un conjunto de casos de prueba, que a falta de ser profundos, prueban todos los caminos de la aplicación y por lo menos, podemos ver, que no fallan las cosas básicas.
Lo ideal es siempre intentar automatizar estas pruebas de regresión, pero lo habitual es que no tengamos tiempo o equipo para realizarlo, así que, al principio, por lo menos, con un esfuerzo extra, las pasaremos a mano.
A la hora de crear un sprint de testing en base al de desarrollo, como ya dije anteriormente, tendremos que dejarnos, al final de este, ese tiempo "extra" para pasar estas pruebas, ya que su utilización mitigará muchos problemas en entornos de producción.
Si en el proyecto que trabajamos, existe una build nocturna que actualiza el entorno que sea con versiones nuevas, lo mejor es que intentemos automatizar estas pruebas (al igual que las unitarias) y que se pasen siempre con ella y para rizar el rizo (que ya es muy complicado) si estas pruebas no pasan en OK, la actualización del entorno no se realiza porque existe algún tipo de fallo. Todo esto en un mundo ideal y sin prisas de negocio, algo que es muy complicado de ver, aunque si que conozco sitios donde lo han conseguido.
Si mantenemos la política de comenzar a utilizar y gestionar bien estas pruebas de regresión, posiblemente nos curemos en salud en muchos aspectos y tendremos un entorno mucho más limpio de fallos colaterales.
0 Comentarios