El cuello de botella del que nadie se hace cargo: El ambiente de pruebas.

Llegás a la mañana a la oficina (sigue existiendo eso?), te preparás un café mientras hablas sobre el clima (de nuevo) con un colega que fue a prepararse los cereales. Volvés contento con tu taza de calentita preparación y mirás los jobs en Jenkins...

Todo rojo. Ya sabés lo que te espera al abrir los mails: varios managers, test leads y gente random preguntando por qué está fallando todo y planteándose si, en lugar de hacer una aplicación, deberían haberse dedicado a plantar girasoles en algún lugar soleado de Nueva Zelanda. 

Necesitás una respuesta, así que empezás a ver el console output o bien los reportes de Cucumber para ver por qué los scripts están fallando si un día antes estaba todo perfecto. Y ahí llegás a la causa: Los Test Users no existen más. Hubo una limpieza de la base de datos y, al no poder loguear, implotaron todos los tests.

Alguien se olvidó de avisar, o de correr el job que crea los users y ahí tenemos la respuesta. Esto es algo que suele pasar más seguido de lo que nos gustaría en la práctica y es algo que impacta el trabajo de testing con tiempo dedicado a la resolución de un problema que no debería existir. Falsos negativos por una mala configuración del ambiente de pruebas... horrible. 

No solo pasa con la data que usamos para testing, muchas veces un proxy, un puerto, un firewall u otra parte de la infraestructura necesitaba un poco de configuración y alguien se olvidó de hacerlo y eso termina en problemas, a veces, muy difíciles de discernir. Les cuento uno por ejemplo que me hizo perder al menos una hora de mi vida. 

Estaba haciendo unos tests de integración en los que necesitaba autenticar dos vías: El servidor y el cliente. A pesar de tener todo bien, el TrustStore y el Keystore de Java, el socket para que Rest Assured use los certificados correctos y demás el tipo me tiraba un error que venía del lado del servidor (un quinientos algo, no recuerdo ahora). Saben qué era? El certificado del Servidor había expirado el día anterior.

Otro caso fue peor! Los certificados estaban bien, no habían expirado, todo seteado perfecto. Sin embargo, no podía conectar al endpoint. Qué está pasando ahora? Requirió habilitar herramientas de debugging siniestras y prohibidas para llegar a la conclusión de que los ciphers, después de un update que hicieron a la configuración del ambiente, eran distintos y ahí estaba el problema. Otro día prácticamente perdido diciendo por mail a los que se encargan de eso: "che...pero de mi lado está todo bien y no se cambió nada en el código, esto TIENE QUE SER LA CONFIGURACION DEL AMBIENTE" para que desestimen hasta que tuve que ponerme algo más picante y poner en copia a pesos pesados. 

Y todos estos problemas muchas veces no están en nuestras manos y el testing se ve afectado al lidiar con resultados que no son verídicos y vueltas que tenemos que dar para dejar el ambiente en condiciones de ser testeado. 

Pero... qué hacer ante esta situación?

Bueno, van a haber veces en las que podemos hacer algo y veces en las que no. Una vez, por ejemplo, hice que la creación de usuarios corriese todos los días antes de que llegue yo y previo a las suites de Automation para asegurarme que siempre los usuarios estuviesen ahí. No me importaba si el job intentaba crear algo que ya existía, era solo para las veces que no estaban ahí. Resultado? Nunca más tuvimos la situación de "está todo rojo pero, después de una hora mirando, nos dimos cuenta que era porque alguien limpió la dB y no creó los users después". Tiempo salvado.

La otra cosa que deberíamos hacer es tener nuestros health y smoke tests como parte prioritaria antes de correr cualquier regresión o set largo de tests. Si el smoke o el health no anda, el ambiente no está listo. Levantamos el ticket y a otra cosa mariposa. Ah...esto me recuerda lo siguiente...

Yo no se si soy yo o si todos lo hacemos (déjenme comentarios!), pero mi prioridad es, si no puedo resolverlo yo o me va a tomar más tiempo del que debería darle, dejar la pelota del lado de la cancha de otro para que lo resuelva. A veces no nos prestan atención, nuestros reclamos quedan enterrados en un backlog interminable, etc. Es lógico, todos tenemos cosas que hacer y a veces se nos juntan, pero bueno... la eficiencia demanda sangre! Entonces, lo que hago es crear un defecto y asignarlo a un dev o persona que se que se encarga del mantenimiento de los ambientes. Si no puedo avanzar, tengo ese ticket que respalda el retraso. Si un manager se enoja, el enojo se redirige al que no resolvió el ticket que tanto mal provocó. 

Es medio mala onda hacer eso? Supongo. Pero como digo (no tan) en chiste en los proyectos: "no vengo al trabajo a hacer amigos, sino a trabajar". 

Esto es todo gente bella, espero que les haya resultado interesante la lectura y me compartan sus penurias ocasionadas por este tema y, si se animan, sus soluciones! 

Ah, les recuerdo que durante todo Julio voy a dejar los Tutoriales gratuitos en Patreon! Aprovechen y aprendan accediendo a todo el contenido que generé en estos últimos años sobre Automation Testing de cero a experto y en Español!