Cuando nos liamos la manta a la cabeza
y tenemos una suite importante de pruebas automatizadas además de un sistema de
integración continua, es casi obligatorio, el unirlo todo y hacerlo funcionar a
la par.
En muchas ocasiones, me encuentro con
que hay verdaderos mundos de pruebas automáticas, pero no existe una integración
con un sistema de este tipo, cosa que hace, que sea difícil el mantener la
calidad como queremos. Todo esto es muy bonito, pero si que es cierto que
muchas veces no está todo integrado porque las pruebas tardan demasiado, no están
suficientemente optimizadas o los resultados obtenidos no están claros o dejan
las trazas suficientes para averiguar posibles problemas.
Una táctica muy buena para comenzar a
integrar nuestras pruebas con un sistema de integración continua es el separar
las pruebas por pesos o tallas (algo parecido como lo que se hace con las
historias de usuario). Un ejemplo de organización puede ser esta:
- Talla XL: Son pruebas que se deben de ejecutar
una vez a la semana, tardan mucho en finalizar, pero su valor es alto. Cubrirán
por completo la batería realizada y darán el OK definitivo al software que
estemos probando.
- Talla L: Pruebas que se ejecutan en más de una hora y que deben de ejecutarse una vez al día. Estás baterías de pruebas son más optimas por la noche, para que si existe algún error, cuando llegue el equipo, podrá solucionarlo.
- Talla M: Estas pruebas son las que están por debajo de una hora y que pueden ejecutarse de manera continua en el software que queramos probar. La táctica ideal es ejecutarlas en la compilación en curso y esperar a que exista una nueva compilación para volverlas a ejecutar.
- Talla S: Son pruebas que se ejecutan de manera muy rápida (en menos de 5 o 6 minutos) pero que forman parte indispensable del KO o KO de la compilación en cuestión. Deben de ser muy rápidas porque los desarrolladores sabrán inmediatamente el resultado y podrán solucionarlo ágilmente. Estas pruebas se ejecutan de manera constante para saber que la compilación sigue en orden.
Aunque parezca redundante, el tener una suite de pruebas que se ejecute constantemente nos dará resultados inmediatos en las pocas líneas de código que se realicen en esa jornada y si existe algún error, se acotará de manera mucho más sencilla.
Estas pruebas, que hemos seleccionado con sus tallas correspondientes, deben de ejecutarse en diferentes estrategias para que los resultados y su efectividad sea total y garantice lo que estamos haciendo. Vamos a revisar algunas:
- Automatizar es vivir. En muchas ocasiones cuando alguien realiza un cambio, tira algunas líneas de código o finaliza el trabajo que tenga que hacer, ejecuta las pruebas para verificar que todo sigue en orden. Para estos casos, tenemos las pruebas automáticas ejecutadas de manera constante, a las que se les van añadiendo nuevas pruebas para ese código en concreto o esa funcionalidad y así sabremos siempre que todo sigue en orden. Por ejemplo, si tenemos una suite de integración continua, estas deben de ejecutarse cuando se hace cualquier commit y se detectan cambios, tanto en local como al subir al repositorio.
- Mejor suite pequeñas. No hay que obsesionarse
con hacer grandes suites de pruebas que tengan que probar todos los resquicios totalmente,
es importante realizar bastantes pruebas de tamaño S y colocarlas en una suite
pequeña que se ejecute de manera muy rápida y ágil.
Esta estrategia unida a un entorno Agile con Scrum, tiene un valor enorme ya que trabajamos con historias de usuario que se pueden atomizar y cubrir con este tipo de pruebas. Además, en integración continua el tiempo es oro, por lo tanto, rapidez y al grano a la hora de probar.
- Una buena configuración nos ahorrará un tiempo muy valioso. Cuando se va a ejecutar una prueba, primero hay que realizar una configuración. Siempre se puede optimizar este paso para que la ejecución sea más rápida y por lo tanto se devuelva el resultado. En muchas ocasiones, pruebas que se ejecutan mediante la interfaz de usuario pueden optimizarse si se prueba a través del API, ahorrándonos timeout, problemas de red y de carga o incluso de apertura del navegador o del ejecutable que corresponda. La ejecución de estas pruebas mediante los ciclos de integración continua nos puede ayudar a mantener estándares que valoremos en el proyecto y, sobre todo, a saber, que se ha roto casi en el momento, cuidando de evitar problemas mayores cuando ponemos todo ese código en entornos de preproducción o de UAT.
Si, además, unimos estas pruebas a una serie de ejecuciones en herramientas como SonarQube, garantizamos que nuestro código, además de no contener defectos, será óptimo y seguro.
Comentarios
Publicar un comentario