El Guardián de las Pruebas: cómo gestionar las pruebas automáticas desatendidas

Los que nos dedicamos a pruebas funcionales automatizadas, nos encontramos con que la mayor parte del tiempo de trabajo efectivo lo pasamos ejecutando nuestros scripts. Estamos acostumbrados a monitorizar la ejecución para intervenir en caso de algún imprevisto y, en mi opinión, creo que es muy positivo reducir nuestra “guardia del muro”.

Como todo ‘Guarda de la Noche‘ debe saber, nuestro muro automático nos protege de muchas amenazas, evitando que estas se internen en los vastos entornos productivos. La Guardia es, en muchas ocasiones, muy pesada; tener que estar vigilando durante largos periodos de tiempo como nuestros scripts se mueven entre un gran número de funcionalidades no es plato del agrado de todos los guardas. Además, estas largas vigilias evitan que nuestras huestes puedan dedicarse a otras tareas más productivas como pueden ser la mejora de las defensas (mejora continua de nuestros scripts) o la reparación del Muro (mantenimientos de los mismos).

¿Cómo podemos reducir nuestras “guardias”?

Un primer paso es identificar tanto los casos de prueba más propensos a detectar defectos como los que cubren las funcionalidades más críticas. El juego restante, lo podemos denominar como de “prioridad reducida”. Este conjunto requiere un menor porcentaje de intervención por nuestra parte por lo que podemos focalizar la monitorización en el resto de casos. Es decir, localizamos los puntos del Muro por los que sabemos que nos llegan más “ataques” y los que son estratégicamente más vulnerables.

Sabiendo dónde están esos puntos críticos, debemos pasar a reforzarlos, revisando en qué sentencias se nos podría quedar bloqueada la ejecución, verificando que el reporte de los posibles errores esté correctamente implementado y añadiendo, si es posible, escenarios de recuperación. Para seguir con el símil, asignando a los guardas más capaces, añadiendo un sistema de comunicación por cuervo de última generación y teniendo siempre preparado un refresco por si las cosas se tuercen en demasía.

Una vez preparados los refuerzos, debemos proceder a comprobar su validez. La mejor forma es realizar varias ejecuciones completas para ir verificando que todos los engranajes están en su lugar, anotando los posibles nuevos puntos de mejora que puedan ir apareciendo y tomando las acciones de corrección correspondientes.

Tras unas pocas iteraciones, tendremos nuestro nuevo sistema de defensa listo para que no dependa de nuestra supervisión como Lord Comandante. Es hora de utilizar alguna de las herramientas de ejecución programada para que se haga cargo de nuestra guardia. ¿Qué podríamos utilizar? Existen multitud de ellas, por ejemplo Jenkins, Control-M o utilizar el programador de tareas del propio sistema operativo, dependerá de los medios a nuestro alcance, lo que Poniente nos proporcione. Todas tienen sus ventajas y particularidades.

Cuando comencemos a delegar las ejecuciones a estas herramientas, comprobaremos lo importante que es el haber identificado los puntos críticos y tener bien implementada la traza de ejecución. Si todo está como sabemos prepararlo, podemos tener plena confianza en los resultados de las pruebas, pudiendo programarlas para horas en las que deberíamos estar descansando de la carga que supone “vestir el negro”.

Valga este post como introducción a la idea de las pruebas automáticas desatendidas, en futuros artículos, profundizaré en los avatares de poner esto en marcha con un ejemplo “real”, abandonando un poco el estilo “fantástico”. Y, recordad…

Soy la espada en la oscuridad. Soy el vigilante del Muro. Soy el fuego que arde contra el frío, la luz que trae el amanecer, el cuerno que despierta a los durmientes, el escudo que defiende los reinos de los hombres.

Jorge Moya

Senior Test Engineer | Digital Assurance & Testing | SOGETI España