Enmilocalfunciona

¿Alguna vez has sentido que estás luchando una batalla interminable contra desarrollo, las expectativas del cliente y las pruebas, sintiéndote sólo ante el peligro? Si has trabajado en equipos de testing y te tomas en serio tu trabajo, esta sensación te será más que familiar.

Demasiado a menudo me he visto sumergido en proyectos donde la cultura de QA del cliente apenas existía. Cada mañana era como adentrarse en una jungla, donde las pruebas se notaban más como una molestia que como una parte esencial del proceso de desarrollo. Los defectos se acumulan, no se les presta la correcta atención excepto cuando es ya tarde o para buscar culpables. Somos como el chivato del cole al que nadie le cae bien.

La falta de información y documentación suele hacer que nuestro trabajo sea un dolor. Como QAs, muchas veces más que probar somos arqueólogos buscando fósiles con los que trabajar, tratando de entender de qué nos están hablando mientras el tiempo sigue corriendo y el cliente presionando para que respetemos unos plazos que han fijado sin tenernos en cuenta. ¿Equipo infradimensionado? Por qué no? Somos maestros de hacer mucho con poco! El que en las películas antiguas hacía un túnel para escapar de la carcel con sólo una cucharilla, seguro que era tester. Como decía aquel lema del comic de los 90, hemos “Nasío pa probá”

En un entorno laboral donde los errores y los plazos acechan como ninjas invisibles, los QAs pueden encontrar una sorprendente fuente de sabiduría en las antiguas estrategias militares de Sun Tzu. Su obra, "El arte de la guerra", ofrece perlas de conocimiento que, aunque pensadas para la guerra tradicional, son aplicables a las batallas en las dailys, que tienen el sarcasmo y los "como ya te conté en el correo anterior..." como armas principales.

Conócete a ti mismo, decía Sun Tzu, y qué importante es! Debes tener claro hasta donde puedes llegar, qué sabes hacer y cuáles son tus fortalezas, elige proyectos donde puedas destacar o empezarás en desventaja. Está muy bien buscar proyectos retadores, pero también se puede morir de tanto reto. Si todo el día estás en sobreesfuerzo, tu autoestima jugará en tu contra y rendirás peor. Sobre todo, no aguantes hasta explotar como un demonio de tazmania, ten en cuenta tus líneas rojas, si lo que haces te lleva hacia donde quieres o te aleja, haz tus pausas y obsérvate o te descubrirás un día tomando ansiolíticos como tu rutina mañanera de trabajo, que ya se han dado casos ¿verdad?

Conoce a tu enemigo: Conoce a tu cliente por encima de todo, las primeras semanas en un proyecto debes tener claro si estará de tu lado o si cubrirá sus espaldas, si puedes confiarle los problemas del proceso o es mejor convertirte en caja negra, si sabe lo que hace o si se escaquea y persigue que testing le saque las castañas del fuego, si es un cliente "mamá gallina" todo el día mirando lo que haces o si es tipo mafioso de peli ("me entregas la mitad del dinero hoy y el resto al finalizar el trabajito"). Sobre todo: ten claras sus expectativas sobre el proceso, el equipo y sobre ti y si crees que no estáis alineados alinearos cuanto antes o llegará el momento del desamor, el despecho, los reproches y la verdadera guerra.

Debes estar preparado y planificarte. Cuántas batallas se han ganado porque uno de los bandos ha estudiado bien el terreno o incluso lo ha preparado con agujeros en el suelo y estacas para los caballos enemigos, aceite inflamable en las retaguardias y demás! las guerras del imperio romano estaban llenas de augustos victoriosos por conocer bien su entorno.

Si han sacado a un equipo de QA para meter al tuyo, pregúntate qué han hecho mal para que pierdan el servicio (y no lo repitas, que no eres más listo que ellos), igual que con los errores tuyos y de tu equipo, puede que no sean justos o que el que lleve la razón seas tú pero no les des oportunidad de hacerte fallar dos veces. Mantén la calma, en muchos eventos scrum vuelan cuchillos y van a buscar que des una respuesta rápida e impulsiva que te dejará vendido, recuerda, más vale un "te lo miro y te digo en unos minutos" a tiempo que estar lamentándose porque le diste mal un dato o una estimación y ahora estas vendido.

Prepárate las reuniones, prepárate los correos, prepárate las llamadas, ten una lista de puntos a seguir y respuestas que debes tener contestadas antes de colgar así como documentación a mano por si la necesitas. ¿crees que soy un paranoico? prueba a saborear las consecuencias de que te consideren experto en algo tras una reunión de 30 minutos en la que no preguntaste lo suficiente y que no se repetirá.

Fórmate, si tu equipo trabaja con selenium y tú estás sólo como funcional manual, fórmate en selenium igualmente. Se pondrá malo algún compañero y te caerá su trabajo o te pedirán explicaciones sobre cómo automatizar tu parte o darán por hecho que lo sabes. Fórmate aunque sea para tener nociones básicas y que las dailys no sean para ti como escuchar a varias zarigüeyas gritándose hasta que alguien dice tu nombre y quitas el mute en teams. Fórmate con una certificación oficial si tienes tiempo, con Udemy si no tienes tanto, con youtube si sólo tienes ratitos o con ChatGPT, pero fórmate. Da pereza, pero hasta los samurais sabían usar todas las armas disponibles en el campo de batalla sólo por si acaso perdían la espada

Evitar una pelea ya es una victoria. Te encontrarás compañeros que dejen que desear, clientes que presionan y faltan al respeto. Gente borde, maleducada, que no se entera, que odian el mundo y te culpan a ti, personas que no hacen bien su trabajo y la culpa dicen que es tuya, gente que se lo tienen muy creído o con tantos complejos profesionales que trabajar con ellos es un suplicio...Mejor no sigo para que no se me escapen nombres. No olvides que seguramente alguien ha pensado algo así de ti también, los conflictos existen porque pensamos y actuamos diferente a como lo haría el otro y, si puedes evitar un enfrentamiento laboral, mucho mejor porque no mellarás la relación del equipo.

A veces es mejor hacerse el tonto que ir de listo. Ganas más con un "disculpa, igual me he enterado yo mal, ayer entendí A y hoy B, me puedes ayudar a aclararlo porfa?" que con un "B? pero si ayer me dijiste textualmente A, abajo te pongo pantallazo de lo que dijiste delante del director, por favor aclárate". Apetece mucho más la segunda opción a veces pero es mejor ser feliz en tu trabajo que demostrar que tienes razón.

Muchas peleas se podrían haber evitado reprobando un defecto en 30 minutos o replanificando una funcionalidad para el siguiente sprint o poniendo el mute y gritar un insulto que haga que el vecino se plantee llamar al 112. Con eso puedes evitar discutir y escalar un problema al scrum master, al PO y que llegue a dirección. Lucha batallas que puedas ganar y que tenga sentido ganar, si la pelea te puede llevar a una mejora sustancial de tu calidad de vida en el proyecto, adelante. Si sólo vas a conseguir un reconocimiento efímero y que ese ITLead no se ponga una medallita a tu costa, sopésalo.

Tu equipo es la clave del éxito. Debes saber en quien te puedes apoyar en cada momento y ser capaces de colaborar. Levanta la mano a tiempo, transmite tus preocupaciones e inquietudes antes de que te roan por dentro o que te explote en las manos. Está claro que contar con un buen líder marcará la diferencia, pero incluso si el liderazgo no es correcto, se puede compensar con una buena organización del resto del equipo entre vosotros. Si vuestro líder no resuelve, dadle problemas resueltos por vosotros. En una trinchera tu compañero es más que tu familia.

Sun Tzu toca más puntos que convierten los enfrentamientos en arte pero llegados a este punto creo que es importante que incluya mi modesta aportación a su sabiduría por encima del resto de puntos de su libro:

Todo por escrito. Todos los acuerdos, asunciones, directrices pactadas, acciones acordadas, paradas de pruebas, redimensionamientos, escalados... todo por correo

Correos con frases como "tal y como hemos hablado...", "este es el acta de la reunión, corregidme por si se me ha pasado algo por favor...", "te resumo para asegurarme que lo he entendido bien...", "copio a mi compañero con estos puntos que hemos hablado para que esté enterado..." y similares, son como tener un batallón de arqueros en retaguardia preparados para cubrirte por si tienes que huir, cambiar de estrategia o por si viene el director a pedirte explicaciones por "cosas que le han dicho de ti". Tener outlook bien organizado y bien nutrido con esos correos de acuerdos te va a salvar de más de una, te lo garantizo.

En resumen

Si has aplicado bien estos principios deberás tener cursos identificados sobre lo que aplique a tu proyecto, cuando los termines tendrás resúmenes de esos cursos aplicados a tu proyecto hechos por ti que te ayuden a ponerte al día rápido si te reasignan o si te toca sacar pecho en eso que no controlabas.

Deberías tener bien calado a "ese" o "esa" de tu equipo, del cliente o de tus jefes y tendrás una carpetita en tu outlook o una etiqueta del correo con su nombre donde guardarás todas sus "joyitas", cambios de opinión o salidas de tono, sólo por si acaso.

Tendrás al día tu agenda, planificarás tus reuniones con "checks" a seguir y pondrás atención a tu nivel de estrés y hora de salida. Si necesitas sistemáticamente horas extra es un problema (tuyo o de la empresa, pero hay que hacérselo mirar)

Tendrás también unos cuantos correos tipo con formas de pedir y decir las cosas de forma más "polite" (que es la palabra que define a darte un ladrillazo en la cabeza, pero metiéndolo primero en una almohada de seda rellena de plumas de cisne). Aquí también puedes usar a chatgpt para que te ayude a reenunciar ese correo cuya bordería haría saltar el antivirus y que no encienda llamas en el interlocutor, transmitiendo la misma información

Espero que, como artistas del testing, dominéis y disfrutéis del arte de mejorar la calidad. Convertirse en un guerrero del código no implica ser agresivo, sino la habilidad de aprovechar cada oportunidad que los equipos nos brinden para encontrar la armonía en los ciclos sin quemarnos en el intento. Recordad, el verdadero arte está en ganar sin luchar: en anticipar y resolver los problemas antes de que se conviertan en batallas mayores sabiendo que somos el último eslabón de la construcción de software y por eso debemos ser los más fuertes y los más preparados.