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