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