Una de las peores cosas que nos pueden pasar en un entorno productivo es una regresión, algo que funcionaba perfectamente y que por una refactorización o un cambio, deja de funcionar.
Cuando nos enfrentamos a regresiones, tenemos dos opciones, agachar la cabeza y aguantar el temporal o tener una buena batería de pruebas de regresión que nos aseguren que toda la aplicación en conjunto funcione como debe de funcionar.
Una regresión puede ser producida, en el mayor de los casos, por algún cambio transversal en otro módulo y que haga fallar una parte de la aplicación que, supuestamente, no se ha tocado.
Para evitar este tipo de problemas, tenemos que tener una buena batería de pruebas de regresión. Esta batería de pruebas hará que tengamos que probar las partes más problemáticas o ciertas partes transversales para evitarnos disgustos sin sentido.
Preferiblemente y bajo mi punto de vista, la batería de pruebas de regresión tiene que ser y estar automatizada, así cada vez que tengamos un cambio de versión podemos, de manera automática, lanzar estas pruebas para comprobar que, efectivamente, todo funciona correctamente.
En cada sprint, nos podemos guardar un tiempo para seleccionar los casos que observemos que sean regresivos y automatizarlos, habitualmente, pueden ser 4 o 5 como mucho, así que nos llevará poco tiempo y nos podemos ahorrar un tiempo muy valioso en cada cambio de versión.
Un buena batería de pruebas tiene que tener indispensablemente todos los elementos transversales que nos encontremos en la aplicación, todos los módulos que tengan más uso o que sean más propensos a estropearse y en el caso de que podamos, puede contener casos que reprueben defectos que sean graves y que puedan volver a ocurrir, por eso es muy importante guardarnos un porcentaje de tiempo para dedicárselo.
Gracias a este tipo de pruebas, podemos evitar uno de los grandes males que nos encontraremos en los entornos de producción y que afectan gravemente la visión positiva que pueda tener un proyecto.
0 Comentarios